I have just a simple, non-threatining, non-hostile question:
BufferedImage seems to be the crossroads for almost every
operation in Java2D. If you are reading an image using ImageIO
then BufferedImages are the object created. Drawing the image
to the screen seems to be focused on drawing a BufferedImage.
I'm skipping details here but overall, BufferedImage seems to
be central to all Java2D ops.
Why not give a little separation between BufferedImages and
general image/imagefile manipulations? Keep BufferedImage as
an important option to display an image and be more flexible
in other operations like reading/writing/modifying an image.
I'm not looking for a fight.....
Dmitri Trembovetski wrote:
[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".
===========================================================================
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".
