[EMAIL PROTECTED] wrote:
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).
Currently there isn't. You can 'pre-warm' the image by copying
it twice to an accelerated destination (a VI or BS) - no need
to copy whole image, just 1 pixel is enough, use
drawImage variant which specifies src and dest rectangles.
I was thinking about adding this ability to affect when the
image is cached through the acceleration priority property.
Say if you set it to 1.0 then we cache it on the first copy
instead of the second.
We already use acceleration priority for disabling
caching of the image (if you set AP to 0.0).
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?)
You can certainly test it yourself, but it should work fine with
built-in plugins, at least in the latest jdks.
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?
There's no way to tell if you rendering operation will be hw accelerated
if that's what you're asking.
You can find if an image is currently cached by using Image.getCapabilities().
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).
Like I mentioned, we may be able to use setAccelerationPriority for that.
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".
Understood. Some of this you could do already - at least check if the image
is currently cached by using Image.getCapabilities() method.
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..?
Yes, you certainly could. May be for the level of control you need
this will be the best approach.
You can also check if VIs are accelerated or not, and only bother
with all this if they are.
Thanks,
Dmitri
[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".
===========================================================================
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".
