[EMAIL PROTECTED] wrote:
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.
It is an implementation detail, related to performance. Of course
it's not part of the specification. Moreover, you may and will
get different behavior when running on say Apple JVM.
Explicitness is the way, IMO.
Again, I disagree. All we can do is explain how _Sun_'s JVM
behaves. We definitely should have better documentation
(like performance guides and such), but stuff like this doesn't
belong to the specification in my opinion.
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?
Sorry, BS is BufferStrategy.
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.
That's the idea. The developer shouldn't be worrying about this stuff,
it should work for most cases. For those cases where the user needs
tweaking or resource management there are APIs like setAcceleratedPriority
and the like.
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.
Understood, but unlikely to happen.
We already use acceleration priority for disabling
caching of the image (if you set AP to 0.0).
Aha. Same as flush(), then?
Not really. flush() drops the cached copies and what not on
the floor, but the image will be cached again the next
couple of times you copy it (or in case of VolatileImages
they'd release their associated vram and you'll need to
'validate' them). setAccelerationPriority(0) makes imange
"unacceleratable", we won't attempt to cache it in vram ever.
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?
Load an image, copy it a couple of times to a VI/BS and check
if it's cached by using getCapabilities() method.
but it should
work fine with
built-in plugins, at least in the latest jdks.
Aha.. JAI ImageIO Tools Blah Blahs also?
That I don't know. The plugin might do something to the image
that would make it unacceleratable (like grab a DataBuffer).
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.
I think someone already filed an RFE for that.
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".
What java version are you using? Have you tried the latest, upcoming
6u10 (available from jdk6.dev.java.net). Some earlier releases did have issues
with images loaded through imageio - they weren't ever cached.
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.
I understand. What I don't get is why you use swing if you're talking about
'fps' and need for speed. Swing's repainting model isn't suited for this kind
of graphics.
If you want more control over rendering you should just use BufferStrategy
and do your rendering.
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.
You misunderstood. If you set the acceleration priority to 0 the
image will be accelerated on he first draw. That is, when you call
drawImage it will first be uploaded into a texture and then
copied from that texture (or rather texture mapped) into the
destination. Some time will be spent uploading the image into the texture
but its insignificant.
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.
Yeah, I hear you. We do need that kind of API.
There are ways to achieve that even now but they're hacky.
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.
May be you do, but many others won't and will wonder why their image is
not updated on the screen. Since this managing of images isn't part of the
API we can't guarantee how other JVM providers will handle this.
In order to provide this api we'll have to expose and document the
internal management mechanism which may not be a bad thing, but
it will limit us in our future attempts to improve it.
For example, Direct3D doesn't really tell you what's happening under
the hood when you create a "managed texture". They just tell you
in which scenarios you should use it. Same with us.
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?
I would like to have something like this added in 7, but
not sure if I'll have time to get to it.
We'll see.
Could you please file an RFE with this request?
"need better management of hw acceleration of images" or something
to that effect. I could file it myself but it's usually better
if someone from outside files it so that it has more "weight".
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.
Why, I think it was a success (the method worked as advertised), you
just didn't like the results =)
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?
It's very similar. You can take a look at it yourself if you like,
java is opensource =)
http://hg.openjdk.java.net/jdk7/2d-gate/jdk/file/
Specifically, the logic for caching images is in
http://hg.openjdk.java.net/jdk7/2d-gate/jdk/file/cd88b4ad7f25/src/share/classes/sun/java2d/SurfaceDataProxy.java
and src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java .
The only difference is that that code operates on SurfaceDatas
which is where the pixels are stored instead of "Bufferedimages".
It's a little hard to see the logic in just those two files,
but the general idea is exactly the same.
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).
Yes, that's true, especially in pre-6u10 releases. The surface will
be moved from vram to sysmem if we detect that you're doing a bunch
of 'unaccelerated' operations which trigger reads from video memory
which are slow. So we relocate the data into the system memory
where it's faster to access.
It's different in 6u10 though - there's none of this 'punting' mechanism
since most of the operations are hw accelerated.
Thanks,
Dmitri
===========================================================================
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".
