> [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.
Ah, interesting. Thanks.
"Slightly" hacky, though. The "dual copy" logic isn't exactly a part of the
specification, as I've understood this.
Explicitness is the way, IMO.
I'm however still not quite into this: what's "BS"? Backing store?! And that
would then be the Graphics2D object that paint(g) is invoked with?
> 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.
Okay, good stuff - but I still think it is magicky. All this; the dual copy
stuff, the now suggested single copy stuff, and whatnot, is probably all good
for common cases where one make a nice GUI for some "enterprise application"
(some database driven stuff), or some slightly more elaborate stuff.
All this magic in such scenarios will just make Swing and Java "go faster", and
their users will be happy.
However, I feel that all this is pretty much just "in the way", and the lack of
explicitness is hurting both my understanding of Java2D and Swing, and my
ability to drive the platform to the fullest (since I can't be explicit about
what I want to "go fast", nor whether it actually already is in the "go
fastest" mode - I can't even microbenchmark things, as you just change stuff
underneath my feet as I try (Managed images, BIs becoming "faster", what Swing
is using as backing ..).
Also, I would like some method to say "NOW!", so that the FIRST drawing was
accelerated.
> We already use acceleration priority for disabling
> caching of the image (if you set AP to 0.0).
Aha. Same as flush(), then?
> > 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,
How? Wrap BufferedImage, and track all methods the loaders invoke? Use some
magic internals of BIs gathered from "read the source"? Load it, then try to
paint it a dozen times, and then check capabilities? Others?
> but it should
> work fine with
> built-in plugins, at least in the latest jdks.
Aha.. JAI ImageIO Tools Blah Blahs also?
> > 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.
Well, yes. I basically want to know "If I draw this thing onto that thing, will
things go fast?". And preferably some way of knowing why it doesn't.
> You can find if an image is currently cached by
> using Image.getCapabilities().
Okay, then ALL of my images aren't. The images alternate back and forth between
using the direct ImageCapabilities, which seem to return false _hardcoded_, and
some CachedDirectDrawImageCapabilities (or what it was), whose source isn't in
the JDK. They all return false for both.
So.. I'm doing something bad. However, I actually find 40 fps for 1280 x 1024
"rather fast".
But what sometimes happen, is that for a while, the drawing takes twice or
thrice the time, but the "intra-drawing pause", the delay between one paint
operation and the next, suddenly decreases from 7-8 ms to 1-2 ms (my paint()
invokes repaint(), to test). I gather that this is about acceleration - in the
first instant, things are accelerated in some way, where the shorter painting
time reflects this, and the larger intra-paint pause is where you blit from one
surface to another (you obviously doesn't page flip, as that would have taken 0
ms, and also, there are apparently no way to get page flipping in windows,
right?). In the second instant, I apparently draw to some slower surfaces, but
then maybe draw directly onto the target, so that the pause is basically zero.
Frustration point: See - I don't know if I manage to convey this - but coming
from the Commodore 64 (!) to this stuff here is hellish. You hide way to much
details, and basically state "oh, let just us handle it - You just relax, we
know this BEST!". But I want to be part of this discussion, so to speak. I e.g.
really can't fathom the point of hiding away Swing's BufferStrategy, when that
obviously would be the good way of making Swing fast. If it isn't, then you
should let me too have access to the better way you use. And I understand even
less why I can't at least override your default, by setting it.
> > 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.
It won't be accelerated until the second draw, which means one slow draw.
And furthermore: What I stated there, was probably more extensive than what you
answered: I want to be able to get to the byte|int arrays (the data), and then
state to the BI: I've modified it, please re-accelerate it - knowing that if I
now change the data, it might not be reflected in the drawing.
I don't even understand the problem of this. A database-backed object will
become stale when changing the data, and the change won't become
visible/permanent in the database unless we take appropriate action. We
understand this. A accelerated BI can become "stale" too. I think we'd manage
to understand that too.
> > 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.
Thanks! Might some of it plausibly be implemented too? At least be taken up for
discussion?
> Some of this you could do already - at
> least check if the image
> is currently cached by using
> Image.getCapabilities() method.
As mentioned, I've already done this, with apparent non-success.
> > 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.
Is this actually what you do for BIs, or do you have some fingers beneath the
hood?
> You can also check if VIs are accelerated or not,
> and only bother
> with all this if they are.
Yes, I already thought about this issue - So I have to stick in logic there
too.
Even volatile images are "magic" in that they suddenly revert to non-VRAM, and
will thus flood the actual ram with TWICE a BI in the above logic scenario
(once for the actual BI, then once while the VI revert to using actual RAM).
Thanks a whole lot for your answers and insight! From the horse's mouth and all!
Endre.
[Message sent by forum member 'stolsvik' (stolsvik)]
http://forums.java.net/jive/thread.jspa?messageID=298576
===========================================================================
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".
