Re: X Rendering and GNU Classpath

[graydon hoare]

Sascha Brawer <address@hidden> writes:

> It seems there are several people with that goal, and that some
> coordination would be good so we can share at least some of the effort.
> Therefore, I guess I'll try to arrange a discussion session during
> LinuxKongress in Saarbrücken/Germany. Jean-Daniel, are you planning to go
> there, by chance?
> 
> Graydon, where are you located? Is there a chance that either you or
> someone else might be present who is familiar with what you are doing on
> top of Cairo/Xr?

I am located in Canada, and it will be somewhat of a trick for me to
get to Saarbrücken. I'll ask my manager, but I can't make any
promises.

I have had a look over the agile2d material, and while I was quite
enthusiastic looking at screenshots and playing with the demo
material, after reading the code I am hesitant to endorse this as a
solution for classpath or gcj. it seems quite specifically an
experiment in java2d *acceleration*, rather than from-scratch
implementation.

In particular, it relies on the existing sun java2d to perform much of
the "tricky" work, such as region and scanline conversion of fonts,
strokes and shapes; glyph selection, shaping and layout. moreover it
does not appear to support porter/duff compositing rules or splines,
nor subpixel positioning of glyphs (the latter is a common problem
when using texture mosaics for hardware-assisted glyphs).

in general terms -- and I don't mean to start a flamewar or anything
-- what it seems to do is (elegantly) copy pixels, matrices and
vectors back and forth between sun's java2d and the video card's
texture buffers, matrix stack and display lists, keeping the requisite
graphics states in sync and accelerating those operations it can with
hardware resources. the result is a good speedup, but it's not
particularly independent of sun's code. 

(a broader concern I have with "hardware accelerated" drawing is that
 there is sometimes an uncontrollable loss of precision and increase
 in ambiguous or unspecified behavior when using consumer graphics
 hardware. for example -- though you'll probably have a hard time
 reproducing this -- my cheapo OGL video card appears to make some
 creative decisions about texel coordinates, such that depending on
 the position of a window on the screen, glyphs in the agile2d demo
 are selected from one pixel further to the left or right than they
 should be, making small (< 24pt) text read like garbage. this is less
 significant with applications like games -- for which the hardware is
 designed -- or for large block-pixel movement commands, but can be a
 problem when attempting to do precise subpixel operations, for
 example rendering and placing glyphs.)

-graydon