RFE: push/pop Java2D graphics state

Java 2D
#1

While developing quite complex java2d applications I’ve faced a number of times the problem to save the current Graphics state (clip,transform,paint,etc.) and restore it later.

The current Java2D implementation forces me to make copies of the objects I’m going to modify and then re-set them in the graphics context later. I suppose this approach is both memory consuming and quite expensive in terms of performance.

I think that the Push/Pop approach would be of great help in order to keep code clean and fast. I think it would also be helpful in order to optimize the new OGL pipeline.

Mik

#2

The whole architecture is already designed around you just calling Graphics.create() on an existing graphics to push the state… and dispose() is your “pseudo pop” (seeing as you can still call any methods you like on the previous graphics objects).

Cas :slight_smile:

#3

I’m aware of create/dispose, but it’s just completely different from pushing/popping the status in a stack. Imagine a recursive approach to painting a scene.

#4

Unfortunately that’s just the way they designed it, which accounts for a little inefficiency and gains a little simplicity. You could wrap the whole lot up in your own push/pop mechanism if you wanted.

Cas :slight_smile:

#5

If only I could recover the graphics context from which the current context was created, i.e.


Graphics current = getGraphics();

current.drawSomeStuff();

current = current.create();

current.manipulate();
current.drawSomeMoreStuff();

current = current.getParent();

// now I'm back in my original context

That would be perty.

Kev

#6

Since the question has a quite important relevance, I’ll post an official RFE anyway…

#7

What do Graphics create() and dispose() actually do? Does create() completly create new object(s) behind the scene? If yes then a push/pop approach might be significantly less expensive.

#8

Unlikely. Push/pop attributes in OpenGL is one of the most expensive operations.

The current design of Java2D means you don’t ever need to get the parent of a Graphics object outside of its scope. It’s not a bad system and is significantly less complicated to use than OpenGL’s stack based state machine.

Cas :slight_smile:

#9

The addition of the push/pop Graphics2D methods doesn’t mean more complexity of the api. You could still use create/destroy. Code compatibility will be guaranteed anyway.

Far from forcing the re-implementation of Graphics2D as OpenGL-like state machine, the addition of the push/pop methods will enable a certain degree of optimization in the pipeline and will help us to keep code very clean, simple and fast.

Try to translate this pseudo code into current java2d code.

g2d.pushContext(AFFINETRANSFORM|CLIP|PAINT); // save AFFINETRANSFORM, CLIP, PAINT
g2d.setTransform(newTransform)
g2d.blabla();
…
g2d.pushContext(FONT); // save current font
…
g2d.setFont(newfont)
g2d.drawString(…);
…
g2d.popContext(); // restore previous font
…
g2d.drawString(…);
…
g2d.popContext(); // restore previous AFFINETRANSFORM, CLIP, PAINT