>In addition the VM would be plugged into > the graphics capabilities and be able to render very fast.
If you start to drop into the graphics devices past the bounds of the published open API's of the graphics devices then you're in for a world of hurt where every single driver update can break compatibility with the system. Using the published open API's should be sufficient enough to enumerate and execute proper graphics optimizations. > know if this is feasible or if the VM and GPU vendors would be > interested in doing this. It just might help in competing with native > code by eliminating a layer that API calls need to go through. Maybe > the Overheads are not as bad I would think. Perhaps even going through > the O/S, if the bridge is in the VM rather than an external library > going through JNI. I know JNI calls certainly have overhead but the VM > itself is native and may not have to go through all the JNI procedures > which cause the overhead. All true, but at the moment anyways, Hotspot definitely uses DirectX or OpenGL under AWT depending on the OS language support, so if you base your graphics on top of AWT, you'll at least get the basic level of graphics acceleration. Look into 'performance AWT' or something like that to find out the little bits and pieces of the platform that are now pretty fast. I'd say that was one of the biggest JVM improvements in the 1.6 generation of hotspot outside of the new GC. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
