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