----- Original Message -----
From: "Chris Campbell" <[EMAIL PROTECTED]>
To: "Michele Puccini" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 27, 2007 4:48 AM
Subject: Re: [JAVA2D] java2d Compositing -> OpenGL fragment shaders
Hi Chris,
thanks for this followup. It's always a pleasure to read your posts.
There's one minor problem with the testcase: the call to Toolkit.sync()
needs to come right after computeImage(), not before it.
I didn't know what Toolkit.sync() does.
The test code is a customized version of something found around.
Thanks for the hint.
Writing accurate microbenchmarks can be a tricky business.
Agreed 100%. You know this was a silly stability case with some little
benchmarking aims in mind. It was not my aim to measure the speed of
random() ;)
Anyway I'm convinced that microbenchmarks are not the only solution for
getting a picture of how the things are working.
Maybe sometimes you also need to spend some cpu time in doing real-world
benchmark code.
I know your car can go at 300Km/h, but did you see the holes in the road ?
;)
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.
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.
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()
--
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.
---------------------------------------------------------------------
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.
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 ?
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.
Thanks,
Mik
============================================================================
ClassX Development Italy Via Francesca, 368/I I-56030 S.M. a Monte (PI) <
Tel.(+39)-0587-705153 Fax.(+39)-0587-705153 WEB: http://www.classx.it <
============================================================================
===========================================================================
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".
