Hi Mik,
On Feb 27, 2007, at 1:30 AM, Michele Puccini wrote:
Also, when you're rendering to a BufferedImage (or "compatible"
image),
you're only measuring the performance of software loops, not the OGL
pipeline. To measure performance of the OGL pipeline, you have to
render
to a VolatileImage.
And what about "managed images" i.e. the capability to auto-
accelerate BufferedImages etc. ?
According to what I read on this link:
http://weblogs.java.net/blog/chet/archive/2003/08/
bufferedimage_a_1.html
"if you want to take advantage of possible acceleration for your
image, use
a compatible image"
I was hoping to get some sort of auto-acceleration from
createCompatibleImage().
This doesn't seem to be the case. Lack of knowledge from my side ?
Mmmh. this is an important point for the java2d community.
Here's the short story:
- If you render *to* a BufferedImage (whether it was created via
the BufferedImage
constructors, or Component.createImage(), or
GraphicsConfig.createCompatibleImage()) with Sun's JDK, then
Java 2D will use
software rendering to get pixels into that image.
- If you render *to* a VolatileImage (and one of the non-software
pipelines is
in use, such as the OGL, D3D, or X11 pipelines), then Java 2D
will use the
native rendering library to get pixels into that image. In the
case of the
OGL pipeline, for example, we'll use native OpenGL calls to
render into that
offscreen image at hardware speeds.
- "Managed images" really only come into play when you're copying
*from* a
BufferedImage into another destination. As of JDK 5 and 6, all
BufferedImages
can be considered "managed images". If you try to copy a
managed image to
a BufferedImage, we will use software loops to do so. If you
try to copy a
managed image to a hardware-accelerated destination, like a
VolatileImage as
I described above, then our image management system will attempt
to cache that
managed image's contents in a hardware surface, such as an
OpenGL texture,
so that copying that image will be accelerated in hardware.
This is the
point that Chet was trying to make in that quote above.
I think we've answered this at various times on the list and on the
forums, but perhaps we should add an entry to the FAQ.
There's a position from Jerry Huxtable about managed images here.
http://www.jhlabs.com/ip/managed_images.html
This is also an important point for the "low-level" java2d community.
Sometimes I get a crash into NVOpenGLPbuffer.exe. Sometimes it
silently
dies.
This is the driver bug I alluded to earlier in 93.71. This bug is
fixed
in Nvidia's next release, but it has been extremely frustrating
waiting
for them to release that new driver (3 months is way too long between
releases)! Until that's released, you can work around the problem by
adding the following to the command line:
-Dsun.java2d.opengl.fbobject=false
Yes, I added this line some tests ago.
Turning off the FBObject seems to fix the problem and the jframe
repaints correctly, but the speed [VolatileImage] is at software
levels both for AA and not-AA lines. Bad news.
Hmm, I don't know why that would be the case. I can try this tomorrow.
When the FBObject is on:
[VolatileImage]
without AA the benchmark time is very low (fast!), but it does
repaint nothing.
with AA the benchmark time is very-very high and still it does
repaint nothing.
In both cases the jframe does not repaint itself anymore after the
first run.
Trying to resize the jframe brings to a crash of NVOpenGLPBuffer.
--
Unhandled exception at 0x69665851 in javaw.exe: 0xC0000005: Access
violation
reading location 0x00000014.
nvoglnt.dll!69665851()
[Frames below may be incorrect and/or missing, no symbols loaded for
nvoglnt.dll]
nvoglnt.dll!69665983()
nvoglnt.dll!69706018()
kernel32.dll!7c80b683()
Again, you're running into the Nvidia driver bug I mentioned. The
performance data you're getting may be bogus.
--
On the couple Nvidia configurations I tried, I got similar
performance
results to what I saw on ATI when rendering to a VolatileImage (more
details below). I would expect OGL to be a win for non-AA
diagonal lines,
and maybe a bit slower for AA diagonal lines.
Currently it is more than a bit.
There are a few small things we can do to improve AA performance.
I'll look into these when I get a chance.
(BTW, the other day I noticed that AA performance with OGL enabled
does seem lower than normal on one of our Nvidia GeForce 7800 boards,
so perhaps there's something else going on here. More investigation
required.)
To track these issues, I filed this bug (will be visible by tomorrow):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6529101
--------------------------------------------------------------------
-
Config 2
--------------------------------------------------------------------
-
WinXP sp2, P4 3.2Ghz HT, 2GB ram, ATI X1600 (drivers catalyst
6.12), jdk
1.5.1_11, jdk 1.6.0 fcs.
on jdk6, volatileimage or compatibleimage, antialias on or off,
ogl on:
Test frame repaint is broken: does not always repaint.
Could you elaborate on this? How is it broken?
On our desktops we use "solid window dragging", i.e. you see the
contents of the window while moving/resizing it.
If I drag the test window outside the screen and then inside, its
contents are not repainted correctly.
Dragging the window across the screen borders I can see the "lines"
test image repainting at wrong offsets like it is "sliding" inside
the contentpane.
Do you mean that you use multiple monitors, and you try to drag the
window between them?
Currently the OGL pipeline is only enabled for the primary monitor,
and then we use GDI for the other screens. This is something I'd
like to address in the future, at least for the case where all the
displays are being driven from the same graphics board.
The test works and I see the lines, even when running multiple
times.
BIG suprise! Using the volatileimage path I get the real OpenGL
speed
(but the antialias must be off)!
Here's what I see on my machine with ATI Radeon 9800 Pro, 2x
2.8GHz P4
(rendering to VolImg using J2DBench):
def: 547.1678467 (var=0.67%) (100.0%)
ogl: 542.0107349 (var=0.0%) (99.06%)
As you can see, there's not much benefit for AA lines, but for non-AA
lines OGL is about 50x faster than the default
I see..
Note that the numbers for AA lines still look pretty bad for OGL when
compared to non-AA. We haven't done any special optimization for
the AA
case yet; we rasterize the line in software, and then do the last
compositing step in hardware. This is an especially inefficient
approach
for diagonal lines, but it's the best way to ensure consistent
quality
across all vendors/platforms. We could potentially use OGL's
built-in AA
lines for simple cases like the one you're using (standalone
lines), but
their quality varies wildly between vendors. (Sometimes you'll
get a 2
pixel wide line when you asked for one, and so on. Not terribly
reliable.) Anyway, if anyone wants to experiment with improving
AA line
performance in the OGL pipeline, please be my guest.
It could be nice to gain low-level access to the FBO pixel memory
and draw AA lines with sw loops there.
You coud gain 100% compatibility and avoid the extra compositing
step. Crazy enough eh ?
Sorry, this low-level framebuffer access isn't possible with OpenGL.
There are already plenty of ways to make this faster, as discussed in
the bug report I just filed. We should definitely be able to beat
software for this case, just give us some time.
on jdk5, the menubar is black (?)
Test frame repaint is broken: does not always repaint.
The test works and I see the lines, even when running multiple
times.
Exiting the test produces a crash. See the PID.
These were known ATI driver bugs that were worked around in JDK 6 and
beyond. At this point, I wouldn't suggest using the OGL pipeline
on JDK
5;
The adoption of jdk6 and the new ogl pipeline is on the roadmap.
Of course you understand my aim to deliver apps that must be as
reliable as possible.
Yep. Thanks for sending all these details. I'm confident that we
can work through them all so that more developers can rely on the OGL
pipeline going forward.
Thanks,
Chris
===========================================================================
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".
