Xegl lives!
Allen Akin
akin at pobox.com
Tue May 24 20:39:29 PDT 2005
On Tue, May 24, 2005 at 05:15:04PM -0400, Jim Gettys wrote:
| Believe it or not, GL doesn't do everything needed for 2D graphics....
| Subpixel text, for one, though Allen Akin was scratching his head to see
| if he could figure out how.
Text is plenty doable, but the crux of the matter is what rendering
model you choose to expose.
For example, "draw an outline glyph with subpixel positioning and
antialiasing using a Porter-Duff composition operator" may cause
problems, because very high quality antialiasing of arbitrary geometry
requires multipass rendering (even with high-end accelerators), and the
rules of arithmetic don't permit some of the useful composition
operators to be applied in multiple passes. To get around this you need
to render to an intermediate buffer and then composite the intermediate
buffer with the target. Doing this under-the-covers can be slow (Switch
rendering to intermediate buffer and composite results for each glyph
individually?) or difficult/fragile (How much memory should you dedicate
to intermediate buffers in order to render multiple glyphs at a time?
What about caching?).
If you're looking for performance, the lowest-level rendering model
needs to expose some of the capabilities and limitations of the
underlying hardware. When you try to apply that to the problem of
rendering AA text, you wind up with an API that duplicates a lot of
OpenGL's -- it has to deal with creating and managing offscreen
rendering areas, selecting blending operators or specifying fragment
shaders, collecting and managing geometry in the form of simple
primitives that can be rendered efficiently, applying hardware AA when
it's available, using imaging operations to merge buffers, etc.
If you're willing to give up GPU acceleration in some of the typical
cases, or don't mind redundant driver development, then you can choose a
rendering model that's more abstract and/or easier to use. From
previous discussions that seemed to be the majority preference, so
that's where I left matters.
But I agree with Jon that the redundant driver development is costing us
time, and that OpenGL- and D3D-capable hardware is what the rest of the
world is targeting across the entire range of devices. I'd add that the
"3D" APIs are still acquiring new functionality, and much of it may be
valuable for "2D" graphics beyond what we're considering today; it's
harder to take advantage of that stuff if we've gone down a different
API path.
Allen
More information about the xorg
mailing list