Re: X Rendering and GNU Classpath

[Sascha Brawer]

graydon hoare <address@hidden> wrote on Wed, 30 Jul 2003 14:34:55 -0400:

>for the past 3 weeks I've been writing parts of java2d, for
>work. specifically I have written a partial java.awt.Graphics2D peer
>object, called gnu.java.awt.peer.gtk.GdkGraphics2D, which supports
>the java2d image model by building cairo[1] surfaces on the underlying
>GDK drawables and painting through the cairo library. I have also
>updated and fleshed out some parts of the geometry and image loading
>classes.

This is great news!

>currently the peer object supports [...]
>
>notably absent are custom strokes, custom compositing operators,
>stroke -> shape conversions, etc.

Stroke -> Shape conversions: IMHO, it would be good to have Java code for
this. It seems something rather central that would also be useful for
porting the code to other platforms. But this is just my personal
opinion, which of course might be biased by my needs.

Could you describe how you handle image buffers? If I may express a wish,
do you think it might be possible to access the raster data through the
java.awt.image framework? For example, this would allow to eventually use
javax.imageio for image conversions.

If you manage to expose the X Render pictures (or whetever Xr/Cairo uses
as an abstraction of those) through java.awt.image.Raster, custom
compositing operators should be doable.  I assume the main problem would
be remote X11, because sending XImages across the network is expensive. 
May I ask how you plan to handle this? Do you keep a local copy of the
buffers? You might also want to have a look at [1] in this context, in
case you haven't read it already.

>it is not clear how mainstream the requirement for these is, but I'll
>hack things into place as necessary.

Actually, I would be most interested in hearing about how you plan to
handle the tricky parts.  IMHO, this is not just a question of hacking...


>shortly I expect to begin playing with text (as soon as carl or keith
>commit a working version of the text API carl recently posted). I am a
>little concerned that sascha's work on java's text rendering API may
>duplicate a lot of work: as a community we have already invested many
>person-years into developing font rasterizers, font configuration
>managers, glyph hinters, unicode layout and glyph shaping systems. I
>feel we should reuse pango, fontconfig, and freetype / xft where
>possible, through simpler JNI bridging.

I fully agree that it makes sense to use libraries such as FreeType,
Pango, fontconfig or Xr on platforms that can assume their presence. But
I see two problems with depending on them:

First, not all users of Classpath have GNOME, or GTK+, or even X11.
There's also systems like Jaos (which uses Classpath on the Oberon
system), or IKVM.NET (uses Classpath on top of .NET), or several projects
for embedded systems, or pure Java OSes.  Surely these are minority
systems, but I find it an important minority, and this not only because I
am part of it.

Second, the Java2D API exposes a lot of things that are internal to
existing libraries. For instance, it might possibly be tricky to do
GlyphVectors on top of Pango. It could as well be easy in this concrete
case; it's just an example.  But if we don't carefully plan such things,
we might end up being able to support only 80% of the Java APIs.

So, I am not saying that we should not use whatever library happens to be
around. However, I also think we should do it in a way which makes it
possible to share code between our diverse projects. In the case of Java
graphics, I think that a lot of code can be common, provided we structure
things the right way.

To give a concrete example, I think it should be possible to implement
GlyphVectors so that the work which is specific to a concrete font
subsystem gets delegated to an interface. People can then implement this
interface in various ways. For your project, it surely would be very
unwise to use my clumsy and buggy font scaler instead of FreeType. But
maybe, we can find an interface for font delegates so that the common
code can use whatever scaler happens to be present?

Of course, it is not exactly easy to find the best way of structuring
code of this complexity. This is also the reason why I am trying to keep
this discussion going, and why I bother to think about how to implement
the Java graphics API on platforms that I personally have no need to
support (such as X11).

Ideally, we can have a common code base for most of Java2D. People could
then adapt it to their own platforms, be it remote X11 or a simple
framebuffer device. Being an object-oriented language, Java offers fairly
good techniques for exactly this kind of abstractions.

Best,

-- Sascha


[1] The Volatile Image API User Guide
    ftp://ftp.java.sun.com/docs/j2se1.4/VolatileImage.pdf
    Describes how to manage hardware-accelerated offscreen images
    (such as double buffers and sprites) with the Java VolatileImage
    class