Hi Chris,
I have some questions below:
On Fri, 3 Dec 1999, Chris Campbell wrote:
> 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.
Java2D has a set of rendering attributes for "Optimize for Speed" vs.
"Optimize for Quality". If the places where there are differences in
rendering are limited to cases where the "Optimize for Speed" attribute
is used, I for one would be happy to have the tradeoff.
By the way, what does the "Optimize or Speed" setting actually do in the
current 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)
>
I'm only going to speak to the last of these points because it's the only
one that directly affects me. I would like to see display lists (as well
as a standard metafile format) in Java-2D. I think it would make sense
to add display list support to a future version of Java for the purposes
of enhancing performance. So I don't see the fact that Java-2D currently
doesn't support that as a problem.
> 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.
>
This sounds like a serious problem. Is it bad enough to cripple any
possible implementation?
> 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...
>
How many possibilities are we talking about? Would it be possible to
have a source-code generator spit out one class for each possible use of
accelerated rendering (thus trading an increased amount of bytecode for
better performance)?
> 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.
>
Are you suggesting that the hardware manufactures are going to have to
produce Java-2D specific drivers in order for Java-2D to take full
advantage of the hardware?
> 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 [EMAIL PROTECTED]
> Sun Microsystems, Inc. (408) 863-3108
> Java 2D Group UCUP02-301
>
> ===========================================================================
> 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".
