RFE: push/pop Java2D graphics state - ACCEPTED

Java 2D
#1

Thank you for reporting this issue.

We have determined that this report is a new bug and entered the bug into our internal bug tracking system under Bug Id: 6350026.

1-2 days and it will appear… then you may VOTE for it…

You can monitor this bug on the Java Bug Database at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6350026.

  1. Voting for the bug
    Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6350026

  2. Adding the report to your Bug Watch list.
    You will receive an email notification when this bug is updated.
    Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6350026

Cheers!
Mik

#2

Have you read the evaluation? They make a good point as to why they don’t have this and aren’t eager to just go ahead and implement it.

#3

Good point indeed. At least we all can live without push()/pop(), but…

Creating and destroying the Graphics does not come for free. This is expecially true for animation. push()/pop() is expensive too, but less.

Maybe push()/pop() and create()/dispose() could coexist. This would give developers the best from the two approaches.

Some benchmarks could outline the cost of create/destroy. In my experience I get remarkable speed gains when saving/restoring the current Color,transform instead of creating new Graphics objects in a paint loop.

Also, I can imagine that a call to dispose() would get rid of any unmatched push/pop calls.

#4

The naive implementation of push/pop in OpenGL, which would do a glPushAttrib and glPushClientAttrib, would be horrendously expensive on any consumer hardware and cause all manner of stalls in the graphics pipeline. (I tried using the GL push/pop stuff once, turns out it’s best left for complex “emergencies”).

Cas :slight_smile:

#5

[quote]…would be horrendously expensive…
[/quote]
Don’t you agree that this is implementation dependent and not api-design dependent ?

#6

No, I think that there’s probably no easy way around it in the implementation. To save or restore arbitrary state is probably going to require a trip over the bus and a flush - and if not probably, then possibly - so it’s like the old glBindTexture quandary - it can be very fast, if the texture’s already uploaded; but it can be very very slow if it’s not, and that’s the case you have to take into account when planning for performance. Given that the worst case scenario could well cause a pipeline flush then I’d be using push/pop state very very sparingly.

Cas :slight_smile:

#7

I think this is a good idea. I think this can be implemented quite fast in Java2D. There should be no need to use glPushAttrib/glPopAttrib. Instead the push/pop stuff should be implemented in java code. There is ofcourse some overhead but nothing dramatic.