Three questions:
1) After a image.flush(), is it possible to somehow indicate to the
BufferedImage (managed image) that I want it to again allocate backing vram?
(Without it having to be drawn twice or whatever - that would be too slow, as I
might only be drawing the image a few times).
2) When using ImageIO, sticking a BufferedImage into the params object
("forcing" the ImageIO to use the supplied BI instead of allocating itself),
will this permanently defeat acceleration for this BI instance? (Basically,
does ImageIO access the data buffer? If it does, is there some magic there that
could internally tell the system to re-copy the data buffer to VRAM?)
3) How can I know whether I have acceleration of the complete drawing sequence
or not? .. whether the BIs in question currently have backing VRAM, and that my
full-screen drawing is running at absolute fullest speed possible? Is about
40-50 frames per second on a 1280x1024 display on a 3GHz P4 with an ATI card
accelerated or not? Basically, is the fact whether you have backing VRAM very
obvious (like 1 fps to 1000 fps), or more subtle?
Background: I have this cache of BufferedImages. For a image organization
application I have, I found that the GC had to work way to hard when I
allocated large 4-10 MPix images in what ends up as a thight loop when the
users "scrolls along" as fast as possible. This gave rise to extreme GC
activity, since no such image (e.g. 7Mx4bytes) is small enough to end up in
eden/survivors, thus all the time ending up in tenured/old space. This results
in that the GC have to do full sweeps to free, apparently employing
stop-the-world tactics (when scrolling fast through images, the app paused for
seconds very frequently). So what I did, was to make a cache of BufferedImages
which I allocate from. This instantly reduced the GC activity to near zero
(since pretty much all BI allocations are removed except for the intial round),
and works like a charm.
What I have ended up wondering about, though, is how this affects acceleration.
I invoke bi.flush() upon re-entry into the cache, since it might be a while
before that specific size image is needed again. What I'd want, is to state
"bi.accelerate()" before giving it out of the cache. Is this possible?
After the ImageIO reading, I'd love if I could state to the BI that "The data
has changed, re-copy the current data to backing vram/volatile image/whatever"
(Or at least that the ImageIO itself did this magically, since everything else
of the BI stuff is magical).
My thought: It would be good if the managed image aspect became a bit more
explicit: In addition to flush(), which obviously is exactly such an explicit
method denoting "I won't be using this BI for drawing for a while (or ever
again), please ditch the backing VRAM", also an "I'm going to begin using this
image again, please allocate backing VRAM", and finally a "The data of this
image has changed - re-copy to backing VRAM, please" method. Maybe also a "is
this BI still managed, or have I done something that defeats it?", in which
case I could invoke the former method. Or maybe just combine the two latter
into "if I've done something to defeat acceleration, then now re-copy the data
into the backing VRAM".
This just hit me: can I precisely emulate everything that you folks do with the
managed image aspect with an extension of BufferedImage that employs
VolatileImages? Thereby I could get all the explicitness I want..?
[Message sent by forum member 'stolsvik' (stolsvik)]
http://forums.java.net/jive/thread.jspa?messageID=298303
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
