NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
thought this would be interesting to many on this list -----Original Message----- [mailto:JAVA2D-INTEREST@xxxxxxxxxxxx] On Behalf Of Chris Campbell Sent: Friday, December 03, 1999 7:34 PM Every so often, a thread will appear on the Java 2D interest list regarding support for hardware acceleration (especially using OpenGL) in the Java 2D API in order to boost performance. Over the past few months, the Java 2D team at Sun has explored many different aspects of the possibility of integrating the OpenGL API with Java 2D. The following is a list of some of the considerations and findings of that study: PERFORMANCE VS. ACCURACY In simple cases (basic geometric shapes and Beziers), utilizing hardware accelerated OpenGL rendering calls boosted Java 2D performance somewhat. However, in many cases the shapes and lines which were drawn to the screen differed visibly from those rendered using the current Java 2D implementation. For example, antialiased lines may look noticably different when drawn by OpenGL rather than Java 2D. Furthermore, these differences in rendering accuracy may vary in OpenGL from implementation to implementation. INCONSISTENCIES BETWEEN APIs A majority of Java 2D rendering methods can be re-implemented using OpenGL without much hassle. Unfortunately, a one-to-one mapping between the two APIs simply does not exist in many cases. For example: - the two APIs interpret compositing (aka blending in OpenGL) rules in slightly different ways - implementing special Java 2D rendering objects such as GradientPaint is difficult in OpenGL (although workarounds do exist) - the full-featured and highly configurable image support in Java 2D is not matched by OpenGL (especially, for example, when dealing with image formats associated with lookup tables) - the Java 2D API does not have any notion of "display lists" in the OpenGL sense (there is no way to take advantage of "precompiled" rendering data in the Java 2D architecture for use in repetitive drawing calls; therefore, OpenGL wouldn't be of much help in this area) MIXING RENDERING CALLS You may be wondering why we couldn't just make up for a rendering technique lacking in OpenGL by simply defaulting back to our current implementation... Well, it doesn't seem to be that simple. While it is possible in some cases to, say, mix GDI or Xlib rendering calls with OpenGL calls, there is sometimes no convenient way to maintain the necessary information required for processing of rendering objects later in the pipeline. The OpenGL framebuffer is able to keep track of this information, but would not be able to interpret any processing that we do internally to the framebuffer, such as rendering text, custom shapes, and so forth. In addition, low-level access to the OpenGL framebuffer is not an option anyway in many cases, which makes things even more difficult. For example, depending on the pixel format, only GDI or DirectDraw calls, only OpenGL calls, both, or neither may be permissible in certain situations. In that light, we find it important to look not only at OpenGL, but also at the role of Direct3D and DirectDraw on the Windows platform, as well as similar alternatives on other platforms. TEXT RENDERING The support for text rendering found in OpenGL is primitive at best. There would be no simple way to rework font support in Java 2D to take advantage of any possible speed-ups in OpenGL. USER AND DEVELOPER SUPPORT >From a maintainability standpoint, supporting the various OpenGL implementations and 3D graphics accelerator cards on the market today is a phenomenal task. In the limited testing that we did between 3 or 4 cards from different manufacturers, we found that the differing functionality between the cards could lead to headaches in the future. For example, Board X can accelerate simple lines and polygons. Board Y can accelerate lines, but not polys. Board Z can accelerate neither lines nor polys. In this example, we may choose to enable OpenGL support for X and Y, but not Z, which seems logical, but what may happen is that in the long run, since Y can't accelerate polys, we would have been better off resorting back to the current Java 2D implementation. It is in those in-between cases where we may be causing a performance degradation rather than a big boost like one would expect. This leads us to the last important point... WE STILL HAVE TRICKS UP OUR SLEEVE There are certain areas in the Java 2D pipeline which we have earmarked for optimization. That is to say, there still remain many crucial, untapped areas where we can increase performance through software, as well as by using current hardware acceleration via GDI and DirectDraw or Xlib. At this juncture, we feel that it is most important to apply our engineering resources to these specific areas and the new architecture, which we are currently working on for an upcoming J2SE release. CONCLUSION In conclusion, a considerable amount of time has been spent exploring the ways in which Java 2D could benefit from a lift from OpenGL. At this point in time, we believe that in order to integrate the OpenGL API with Java 2D, we would be "shoving" code in here and there to get any favorable results. The new architecture mentioned above eliminates much software overhead and is pluggable enough such that it allows hardware manufacturers to devise the best optimizations for many operations at a fine-grained level. In this case, utilizing OpenGL acceleration is not an "all or nothing" endeavour; we can accelerate very specific operations as long as we can find an adequate resolution to the "mixing calls" issue. We are not turning our backs completely on the idea of tapping hardware for acceleration purposes. We already take advantage of hardware acceleration for drawing directly to the screen using GDI for cases that GDI can support. We are looking at how to generalize that support to include offscreen images. We will also continue to explore the possibility of utilizing OpenGL, Direct3D, DirectDraw for possible performance enhancements across many platforms, and we will certainly report on this again at a later time. Chris -- Chris Campbell christopher.campbell@xxxxxxxxxxx Sun Microsystems, Inc. (408) 863-3108 Java 2D Group UCUP02-301 ======================================================================= == To unsubscribe, send email to listserv@xxxxxxxxxxxx and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to listserv@xxxxxxxxxxxx and include in the body of the message "help".
visad archives: