|
hi mauricio,
thank you for the insight. you were talking
about the acceleration between 32 and 16 bit mode issue. what about the
clipping issue which causes system hangs? is that also limited to
Win2k?
as for the pixel format, printing the
GraphicsConfiguration.toString() (via
Canvas3D.getGraphicsConfiguration().toString() ) prints something named
pixfmt=<num>. i'm assuming (big handwave) that that is the actual
pixel format. i've decompiled some J3D .class files and in
NativeConfigTemplate3D.java there's a function called
GraphicsConfiguration
getBestConfiguration(...)
which in turn calls a native function
called
native int choosePixelFormat( int, int[]
)
think that's the function which can shed some light
as far as how the pixel format is choosen...
but the clipping issue is the main butt
buster. i have no insight on it with the only assumption that ATI's
graphics is accessing bad memory when the window is clipped and causes the
hang. but interesting enough, i can't get any sample native C OpenGL demos
(ie Glaze, 3Dlabs demos) to crash when clipped. so even though it's not
the fault of Java3D's, there is still definitely that J3D's doing that's
different from the OGL demos which causes ATI's driver to go down a specific
buggy code path.
Jack Pien
Asenza Corporation
(650)838-0068
----- Original Message -----
Sent: Wednesday, February 07, 2001 12:48
PM
Subject: Re: [JAVA3D] ATI Rage Mobility
128 M4 and Hardware Acceleration
Jack,
You
are correct, the issue of hardware acceleration with Java 3D 1.2 has been
discussed, but has not been adequately resolved.
Here
is a summary of what is known so far: This problem appears to be limited
to Windows 2000, and not Windows 98 or NT. On Windows 2000, some
graphics cards and drivers work properly, usually when running
at 32-bit color. Specifically, I have found that any GeForce or
TNT-based card with the Detonator 3 driver running at 32-bit color will
provide OpenGL hardware acceleration under Windows 2000. Also, RAGE
MOBILITY chips using the latest driver can run Java 3D with hardware
acceleration at 32-bit color (although the hardware acceleration is not
substantial).
I
believe there is very little reason for Java 3D to select non-accelerated
pixel formats, when a native (C++) application can easily select an
accelerated pixel format with the same resolution and color depth.
Remember that access to OpenGL is done by the Java 3D DLLs with native
code. Can anyone on the Java 3D team who is familiar with the pixel
format selection code shed some light on this?
Jack, how did you determine which pixel format was
selected by Java 3D?
hi,
i was wondering if anyone has ran Java3D
(1.2OpenGL w/ Java1.3) on an ATI Rage Mobility M4 128 (on a Dell Inspiron
8000). i see a consistent system hang which requires a
reboot whenever you clip the Java3D window (running any j3d demo app)
with another window or against the edge of the screen. J3D works if
it's not clipped, just when you start dragging a window over the Java3D
window, you'd get a hang after some dragging and clipping. this is
most likely a graphics driver bug but just wanted to see if anyone has seen
the same problems - or better yet, if anyone knows the reason for the
hang.
also, it also seems like the ATI Rage Mobility
only accelerates in 32 bit color mode (i saw someone post this phenomenon in
a past thread but didn't see a resolution). 16 bit color mode seems to
lead to use of a non-accelerated pixel format (ie HelloUniverse uses pixel
format 3 or 4 in 32 bit mode but pixel format 12 in 16 bit mode). but
when i run some OpenGL benchmarks (like Glaze, 3Dlabs sample
demo/benchmarks) they all seem to accelerate fine in 16 bit color
mode. anyone see this? reasons?
thanks.
Jack Pien
Asenza Corporation
(650)838-0068
| 