Hi Thorn,
"Thorn G. Green" wrote:
>
> Hi Chris,
>
> I have some questions below:
>
> On Fri, 3 Dec 1999, Chris Campbell wrote:
>
> >
> > 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?
>
Currently, the KEY_RENDERING hint is used internally to determine things
such as which ColorModel to associate with a BufferedImage, or which
image interpolation scheme (bilinear/nearest neighbor) to utilize for an
AffineTransformOp on an image.
> >
> > 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?
>
It seems to be implementation dependent. We will continue to
investigate this matter in order to find an optimal solution.
> > 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)?
>
Well, considering the number of 3D graphics boards on the market today
and in the past, I'd say there could be quite a large number of varying
implementations. Writing X number of bytes of redundant code is clearly
undesirable. A more viable solution that we are considering is to
utilize hardware acceleration in certain areas where the gain would be
most advantageous and where we can determine that most, if not all,
implementations of a certain API will produce the desired result, such
as (possibly) in alpha compositing operations.
> > 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?
>
I should have been a little clearer in that statement... If
manufacturers have, for example, really optimized blit operations in
hardware for OpenGL and/or Direct3D, then the new Java 2D pipeline
architecture would be able to take advantage of these fast hardware
devices and drivers. I didn't mean to imply that manufacturers would
have to create Java 2D specific drivers, but rather that we might be
able to harness those hardware implementations for performance boosts on
certain operations.
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".
