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 [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".
=========================================================================== 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".
