[EMAIL PROTECTED] wrote:
This is a good discussion..
[EMAIL PROTECTED] wrote:
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 meant explicitness in the code, access to "lower levels" or at least methods
that query/specify aspects of this - NOT explicitness for this stuff in the specs.
You can't have "access to lower levels" unless you have a public
API, which will be part of the spec.
What I meant about "hacky" is exactly that I think the "dual draw for
acceleration" is really hacky, and is in no way suitable for spec addition!
I'm not sure why you consider this hacky, it's just a
heuristic for detecting when image is copied from
"enough" times. Two times works just fine for 99% of the
cases.
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.
(I edited the original post slightly, but you apparently reply using the email
interface..)
I meant that first the BI has Capabilities of class "java.awt.ImageCapabilities", then it
becomes "sun.awt.image.CachingSurfaceManager$ImageCapabilitiesGc"..
What does this signify?
However, they return false for both Accelerated and TrueVolatile in both cases.
I guess that means that they aren't accelerated.
Another way to test is to run your application with -Dsun.java2d.trace=log
and see what is being printed when you call drawImage for these images.
Easiest way to do this is to put some printlns before and after
the drawImage call, then you'll be able to find that piece in the
log.
What GraphicsConfiguration do you pass to getImageCapabilities?
Question here: When I draw onto the "Swing surface", the Graphics object that
I'm presented with in the paint method of e.g. a JComponent, will BIs become accelerated?
Is that Graphics2D instance a VolatileImage or a BufferStrategy? I would think so, how
else could this stuff be truly accelerated? .. but I don't quite get the logic.. Or maybe
it is something else entirely?
Swing's backbuffer (which is what your component renders to) is either
a VolatileImage or BufferStrategy (depending on some factors),
so yes, it should be accelerated in most cases.
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.
Well, I want Swing for widgets and LayoutManagers and such, and then I want a
hole in the middle where I can draw, really really fast.
But this isn't quite what we're talking about, is it? The BufferedImages and such are
still "magicy"?
Not magic-y, they're "managed".
This is probably a dumb question, but I don't get it: Is Swing still a
free-standing library, as it was intially? (According to O'Reilly's Java2D 2nd
ed. One could download it separately - it only utilized AWT). That would
ultimately mean that one could run Sun's Swing on top of another JVM that had
AWT fully implementer. Or has the borders become blurry, with Swing doing
native, or at least invoking behind-the-scenes stuff with the SunGUIToolkit or
whatever those classes are called?
It is not, it depends on some internal APIs (not too many, though).
Some parts of Swing (like native look and feels) have to use native
code, for example.
Follow-up: At which point is the interface between AWT and Swing? What is the latest
point where I am "on the low level", drawing-wise? Frame.paint()?
JFrame.paint()? Because at JComponent.paint(), Swing has somehow taken over, right?
Why don't you take a look at the sources and find out?
It's just too vague of a question to answer shortly. Swing does
have its fingers in JFrame (and I think Component as well).
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.
Yeah, that was what I meant, though.. Like the FIRST drawing will get the hit
of copying the BI to the VI, before being drawn. It would be nice if even that
could be avoided.
If you want to control when the image gets uploaded
use the technique I suggested in my previous post.
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.
Yeah, okay. I've always thought that the concept of "secretly" or "magically"
doing this managing was a bad idea. Why not instead make a new extension to BI that was explicitly
called ManagedImage. Thus you could make these effect explicit, by stating that if you grab the
data buffer and change it, you must invoke such and so and blah blah blah - all this would be
OBVIOUS even.
Because when BufferedImage became "managed" there were already
thousands of applications out there, which instantly benefited
from it becoming "managed". If we added a new class those
applications will have had to be rewritten to take advantage
of this new "managed image".
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".
This is SERIOUSLY not the case! This is much better coming from you. I'm a worthless
customer (seriously), you're "at least" a developer on the actual team! RFEs
seldom lead anywhere, IMHO.
You don't understand how this works. External input is
more important than internal.
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
ttp://hg.openjdk.java.net/jdk7/2d-gate/jdk/file/cd88b4
ad7f25/src/share/classes/sun/java2d/SurfaceDataProxy.j
ava
and
src/windows/classes/sun/java2d/d3d/D3DSurfaceDataProx
.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.
Thanks a bunch, I will look into it! I "just" need to connect the dots
regarding a) What type of surface the Graphics2D object presented to the different
paint() methods is, b) How the internal BufferStrategy stuff of Swing works, and c) How a
and b interacts with BIs and VIs. And possibly also what the BufferStrategy really is..
a) take a look at Component, JComponent, JFrame
b) take a look at BufferStrategyPaintManager in src/share/classes/javax/swing
c) BS is basically (this is oversimplification) a bunch of VolatileImages
hidden behind some API. Since the implementation is hidden they may be
something completely different.
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".
