Skip to main content

[JAVA2D] java2d.opengl=true

13 replies [Last post]
Anonymous

Hello,

I recently read that JDK 1.5 will get "native hardware acceleration from
Java2D" if they have the "latest OpenGL drivers and select graphic
cards."

Where can I get more information about this. We will be running on
Windows XP.

Thank you,

Ted Hill

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jim Graham

> Now one quick question comes to mind with respect to my other
> application. If translucency isn't currently hardware accelerated - is
> Java actually doing pixel tests for overlapping translucent objects?
> If so, that would explain my performance woes. I would only want to
> draw translucent stuff if I knew it was hardware accelerated.

I'm not sure what you mean by "pixel tests for overlapping translucent
objects".

Whenever you draw translucently, if we software render it then it is a
read, modify, write operation. We should have tests in most places
that test "if alpha is opaque then just write the pixel", though. Have
you done tests that show that translucent rendering is too slow? I'm
wondering why you prejudge that it won't be possible without hardware
acceleration. There are a couple of things to be aware of for best
translucent rendering, though.

For example, software rendered translucency to a BufferedImage will be
much faster than translucency to most accelerated framebuffers until we
get acceleration for the translucency. The reason is that most of the
latest framebuffers are much slower to read a pixel than to write a
pixel and the operation will bypass the processor cache, whereas a
BufferedImage will be stored in system memory and reading and writing
will be just simple memory operations to the processor's cache.

If you have an operation that is doing Area calculations on RR2Ds and
also rendering them translucently, I would think you are being hurt
more by the Area operations than by the blending operations, even if
they are software. But, if you are rendering translucency directly to
the fb, then that may make the difference due to the added overhead of
poor readback performance from the framebuffer, but Area is not very
efficient with large numbers of objects...

...jim

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gregory Pierce

>
> I'm not sure what you mean by "pixel tests for overlapping translucent
> objects".

Additive blending in the frame buffer.

>
> For example, software rendered translucency to a BufferedImage will be
> much faster than translucency to most accelerated framebuffers until we
> get acceleration for the translucency. The reason is that most of the
> latest framebuffers are much slower to read a pixel than to write a
> pixel and the operation will bypass the processor cache, whereas a
> BufferedImage will be stored in system memory and reading and writing
> will be just simple memory operations to the processor's cache.
>

I will try rendering everything into BufferedImages (since Volatile
ones don't support transparency) and then blen the two images
together.

Approach:

What I did was compare renderingMethod0() which is the rendering of
all of the shapes with no form of clipping with 1000 RR2Ds with a
translucent color and it was taking about 1200-1300 ms. I considered
this slow. I swapped the shape to a regular rectangle to make sure it
wasn't the curve that was causing the performance problems and it was
in the same ballpark - maybe 100ms less. I know with absolute
certainty that its not that slow running on Radeon class hardware with
OpenGL drawing objects of the same size with a screen size of 1024x768
with a bit depth of 32. (comparing rectangle draw to rectangle draw on
each). So I know with absolute certainty that I can get it faster
doing raw OpenGL - that much was never in question for me.

What isn't clear is what the optimal path is for drawing at the same
rate in Java2D.

I'm following a scientific approach, comparing different approaches by
adding on functionality and comparing different algorighms. My opinion
isn't prejudiced yet - I'm speaking from the results I'm seeing and
from my work porting JOGL to MacOSX, working commercially with OpenGL,
authoring works in DirectX, and even doing the same number of pixel
shaded (actually more) quads in 3D space on nVidia 5200FX hardware
(which is dog slow). The numbers I'm seeing don't lie - something
about what I'm doing to Java2D is very very slow and its difficult for
me to figure it out.

I wish someone would do a "Trip down the graphics pipeline" for Java2D
so people could see what's happening under the covers :)

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Jim Graham

> What I did was compare renderingMethod0() which is the rendering of
> all of the shapes with no form of clipping with 1000 RR2Ds with a
> translucent color and it was taking about 1200-1300 ms. I considered
> this slow. I swapped the shape to a regular rectangle to make sure it
> wasn't the curve that was causing the performance problems and it was
> in the same ballpark - maybe 100ms less. I know with absolute
> certainty that its not that slow running on Radeon class hardware with
> OpenGL drawing objects of the same size with a screen size of 1024x768
> with a bit depth of 32. (comparing rectangle draw to rectangle draw on
> each). So I know with absolute certainty that I can get it faster
> doing raw OpenGL - that much was never in question for me.

Another test would be calling fillRect() 1000 times. Calling
fill(Shape) has additional overhead issues beyond our potential fill
rates.

Also, as I added before - blending rates to BufferedImages should be
much faster than blending rates to the screen or volatile images
(though volatile images will voluntarily punt themselves to system
memory if you do too many read operations on them - the screen must
always live in VRAM).

> I'm following a scientific approach, comparing different approaches by
> adding on functionality and comparing different algorighms. My opinion
> isn't prejudiced yet - I'm speaking from the results I'm seeing and
> from my work porting JOGL to MacOSX, working commercially with OpenGL,
> authoring works in DirectX, and even doing the same number of pixel
> shaded (actually more) quads in 3D space on nVidia 5200FX hardware
> (which is dog slow). The numbers I'm seeing don't lie - something
> about what I'm doing to Java2D is very very slow and its difficult for
> me to figure it out.

As far as I know OpenGL has no "Round Rectangle" primitive so I'm
curious how you communicated your RR geometry to it. Also, were you
driving OpenGL in immediate mode (i.e. invoking it once for each RR) or
were you batching them up in one very large triangle list?

...jim

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gregory Pierce

As I stated, I reduced the problem to regular rectangles in order to
compare the drawing speed to regular GL which has functions for
drawing quads.

I was not doing anything to batch up the commands using either a VAR,
nor triangle list. I compared the operation doing exactly what I'm
doing now.

glBegin(GL_QUADS);
...
glEnd();

I can put this somewhere on the web if you guys want to take a look.
Drawing basic primitives filled with a single color is trivial in GL.

At the moment I've backed all the way back and I'm not clipping at
all. Now I AM interested in figuring out if its Java2D itself that's
slow. I'm running about 100 tests throughout the day that will draw a
thousand regular rectangles (to get a performance loss compared to
immedate mode DirectX or GL rendering) and compare that to the numbers
that I already have from the immediate mode tests. I will then compare
that to doing the same thing in BufferedImages to see how much
performance increase I get.

This is all quickly becoming fascinating to me because coming from my
work on JOGL I expected that an OpenGL accelerated pipeline would be
in the same ballpark, and I'm not really finding that to be the case.
I know that the pipeline implementation is early, but perhaps my
expectations may be a little bit different from yours.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Chet Haase

Hi Ted,

I'm not sure what level of acceleration you are looking for, but there
is already
hardware acceleration by default on the Windows platform on nearly any
driver/card combination. However, this acceleration is only for the
most rudimentary
operations (rectangular fills and copies); this results in much better
performance for simple GUI apps (everything but text tends to get
hw-accelerated),
but doesn't do much for apps that really drive the 2D features.

The new OpenGL pipelin in Java2D enables much more acceleration capabilities
(for things like translucency, transforms, and anti-aliased text) in
addition
to the basics. The catch is that our use of OpenGL requires certain
features
which are not enabled on some hardware (especially older hardware) or which
some drivers do not accelerate. Also, since we tend to use the hardware and
drivers in different ways than typical GL apps (we are not Quake...), we
have
seen problems with both robustness and performance on some platforms. For
example, the latest Windows ATI drivers seem to have a problem not
crashing when we
are using GL.

Thus, our decision to only enable GL acceleration with a runtime flag:
sun.java2d.opengl=true.
It's there for people that really want to try it out, to see if it works
on their
specific runtime platform. It's not advisable to enable it for an app that
ships on unknown platforms due to the issues I mentioned above.

There is more info about our OpenGL support here:
http://java.sun.com/j2se/1.5.0/docs/guide/2d/new_features.html
(I got to this by drilling down on a few links from the 5.0 release page).

Good luck!

Chet.

Ted Hill wrote:

> Hello,
>
> I recently read that JDK 1.5 will get "native hardware acceleration
> from Java2D" if they have the "latest OpenGL drivers and select
> graphic cards."
>
> Where can I get more information about this. We will be running on
> Windows XP.
>
> Thank you,
>
> Ted Hill
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body of the message "signoff JAVA2D-INTEREST". For general help, send
> email to listserv@java.sun.com and include in the body of the message
> "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gregory Pierce

Hi Chet. Is there a way to enable/disable while the app is running? I
saw that you called it a runtime flag, but I'm assuming that means
that you pass it when your application is first started.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

You can enable it in your main method, prior to initializing
anything awt-related:
System.setProperty("sun.java2d.opengl", "true");

But we would discourage you from enabling it by default in your
application: consider that your customer may be running it on a
system with sub-par opengl drivers implementation, and the app
crashes on startup.

Also, some opengl implementations have performance issues, so
the application may actually run slower than with the default
pipeline.

Thank you,
Dmitri

On Tue, Sep 07, 2004 at 11:08:06AM -0400, Gregory Pierce wrote:
> Hi Chet. Is there a way to enable/disable while the app is running? I
> saw that you called it a runtime flag, but I'm assuming that means
> that you pass it when your application is first started.
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gregory Pierce

I was thinking more in line of having a checkbox in a config that the
user could check once they wanted to check OpenGL acceleration. So I
wanted to allow the app to start unaccelerated, then have the user go
into the application preferences and click "Enable OpenGL
Acceleration".

Now one quick question comes to mind with respect to my other
application. If translucency isn't currently hardware accelerated - is
Java actually doing pixel tests for overlapping translucent objects?
If so, that would explain my performance woes. I would only want to
draw translucent stuff if I knew it was hardware accelerated.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Chet Haase

>I was thinking more in line of having a checkbox in a config that the
>user could check once they wanted to check OpenGL acceleration. So I
>wanted to allow the app to start unaccelerated, then have the user go
>into the application preferences and click "Enable OpenGL
>Acceleration".
>
The only way this could work is if you spawned a new Java process based
on a change to
this setting; we read the opengl parameter (whether in main() or on the
command-line)
at process startup time (when AWT/2D is first initalizing). We have no
facility for switching
gl support once we've started up.

>Now one quick question comes to mind with respect to my other
>application. If translucency isn't currently hardware accelerated - is
>Java actually doing pixel tests for overlapping translucent objects?
>If so, that would explain my performance woes. I would only want to
>draw translucent stuff if I knew it was hardware accelerated.
>
There's a couple of answers here:
- You could also try out d3d translucency acceleration. This is also
disabled by default (also due to
robustness issues, but driver support seems much better for this
capability and we were actually on the
verge of enabling this by default in 5.0). You can enable this with
-Dsun.java2d.translaccel=true.
This forces us to use Direct3D for translucent image operations (such as
drawImage() where the
source image has alpha). Note that this does not speed up other
translucent operations (lines
with alpha colors, etc.). But when it works (which it should on most
modern graphics
accelerators), it give sa huge boost in translucent image performance.
Note that we also init d3d support at process startup time, so you also
cannot switch this
capability on the fly.

- By default, we're not accelerating translucent operations of any
kind. This means that we're
doing read-modify-write on the destination pixels. This is a hideously
expensive operation when
the destination lives in video memory; reading from VRAM is one of the
slowest operations known
to man, measurable more in geologic ages than clock cycles. One
workaround we have internally
is that when we detect a large number of reads from VRAM compared to the
number of
accelerated copies from that surface (for example, if you read or
read-modify-write over an
eighth of the buffer on any given frame) we will punt this destination
buffer to system memory,
where reading is much faster. This means that the translucent
operations go faster, although
it defeats acceleration for opaque operations to/from that buffer.
So yes, this could be the source of your performance woes.

Try out opengl. Try out d3d (translaccel)). See if they help address
your problems.

Chet.

>
>===========================================================================
>To unsubscribe, send email to listserv@java.sun.com and include in the body
>of the message "signoff JAVA2D-INTEREST". For general help, send email to
>listserv@java.sun.com and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Chet Haase

By the way, just to be totally clear on the subject of our
hardware acceleration support for various platforms:
- GL support is available (disabled by default, enabled via
the sun.java2d.opengl=true flag) on all Sun-developed platforms
(Solaris, Linux, and Windows).
- Direct3D support is only available on Windows (DirectX
support is enabled by default, but use of Direct3D for
translucent image operations is disabled by default, enabled
via the sun.java2d.translaccel=true flag). Pretty obvious,
since DirectX is a Microsoft/Windows graphics library, but I just
wanted to spell it out to avoid confusion.

Chet.

Chet Haase wrote:

>> I was thinking more in line of having a checkbox in a config that the
>> user could check once they wanted to check OpenGL acceleration. So I
>> wanted to allow the app to start unaccelerated, then have the user go
>> into the application preferences and click "Enable OpenGL
>> Acceleration".
>>
> The only way this could work is if you spawned a new Java process based
> on a change to
> this setting; we read the opengl parameter (whether in main() or on the
> command-line)
> at process startup time (when AWT/2D is first initalizing). We have no
> facility for switching
> gl support once we've started up.
>
>> Now one quick question comes to mind with respect to my other
>> application. If translucency isn't currently hardware accelerated - is
>> Java actually doing pixel tests for overlapping translucent objects?
>> If so, that would explain my performance woes. I would only want to
>> draw translucent stuff if I knew it was hardware accelerated.
>>
> There's a couple of answers here:
> - You could also try out d3d translucency acceleration. This is also
> disabled by default (also due to
> robustness issues, but driver support seems much better for this
> capability and we were actually on the
> verge of enabling this by default in 5.0). You can enable this with
> -Dsun.java2d.translaccel=true.
> This forces us to use Direct3D for translucent image operations (such as
> drawImage() where the
> source image has alpha). Note that this does not speed up other
> translucent operations (lines
> with alpha colors, etc.). But when it works (which it should on most
> modern graphics
> accelerators), it give sa huge boost in translucent image performance.
> Note that we also init d3d support at process startup time, so you also
> cannot switch this
> capability on the fly.
>
> - By default, we're not accelerating translucent operations of any
> kind. This means that we're
> doing read-modify-write on the destination pixels. This is a hideously
> expensive operation when
> the destination lives in video memory; reading from VRAM is one of the
> slowest operations known
> to man, measurable more in geologic ages than clock cycles. One
> workaround we have internally
> is that when we detect a large number of reads from VRAM compared to the
> number of
> accelerated copies from that surface (for example, if you read or
> read-modify-write over an
> eighth of the buffer on any given frame) we will punt this destination
> buffer to system memory,
> where reading is much faster. This means that the translucent
> operations go faster, although
> it defeats acceleration for opaque operations to/from that buffer.
> So yes, this could be the source of your performance woes.
>
> Try out opengl. Try out d3d (translaccel)). See if they help address
> your problems.
>
> Chet.
>
>>
>> ===========================================================================
>>
>> To unsubscribe, send email to listserv@java.sun.com and include in
>> the body
>> of the message "signoff JAVA2D-INTEREST". For general help, send
>> email to
>> listserv@java.sun.com and include in the body of the message "help".
>>
>>
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff JAVA2D-INTEREST". For general help, send
> email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gregory Pierce

How does one enable the opengl pipeline in a webstart application in
JDK1.5? I've looked through the documentation for webstart, but its
not entirely clear where the -D parameters should go in the JNLP file.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Praveen Mohan

Hi,

Please go through the following link:

http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/syntax....

Looks like if the property is not listed in the 'secure' list then the
application has to handle that using the System.setProperty(), by
setting a flag thru JNLP file.

-Praveen

Gregory Pierce wrote:

> How does one enable the opengl pipeline in a webstart application in
> JDK1.5? I've looked through the documentation for webstart, but its
> not entirely clear where the -D parameters should go in the JNLP file.
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

--

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Gregory Pierce

Yeah, that's what I was reading through and it didn't mention any of
these new flags. It seems odd that I can sign the application and
effectively have control of the box through native libraries, but not
be able to sign the application and get hardware rendering. Is this
something that I should address through the webstart folks? If its
signed, it should just let me pass any -D parameter in the JNLP file
and it should just work.

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".