On Thu, 27 Feb 2003, Kendall Bennett wrote:
> Mark Vojkovich <[EMAIL PROTECTED]> wrote:
>
> > What are you guys talking about? XAA already has hooks all over
> > the place.
>
> Yes, it does! Now that I am learning more about this I am happy to see
> that someone saw fit to make it so XAA drivers can hook stuff at many
> levels. Very cool. It should be better documented though ;-)
I think there are very few reasons to hook stuff at higher levels.
I don't believe you have a reason to do so.
>
> > XAA already does this!!! XAA has never cached glyphs in video ram.
>
> Hmm, then how come in the XAA driver architecture there are methods to do
> mono blits from offscreen video memory? I just assumed that this meant
> the glyphs were being cached in offscreen video memory, but perhaps XAA
> is just using offscreen memory as a temporary 'ping ping' buffer in this
> case? Ie: for hardware that can't do system blits but can do blits from
> offscreen video memory?
Mono blits from offscreen are only used for cached stipples.
If the driver supports these it is the prefered method for stippling.
Otherwise XAA will fall back to transparent blits from the pixmap
cache or CPUToScreenColorExpansion.
XAA's catch-all for non-AA text rendering renders each glyph with
WriteBitmap. If the driver didn't provide WriteBitmap, XAA would
provide one that used the driver's CPUToScreenColorExpansion routines.
If the conditions were appropriate XAA would pre-composite the whole
string and pass the result as a single bitmap. These conditions
are that no glyph is more than 32 pixels wide (it's optimized to
expect it to fit in one DWORD) and the rop is such that it doesn't
matter if glyphs overlap (if the rop it XOR, for example, overlapping
characters are supposed to XOR each other and a pre-composited
string would be incorrect if it contained overlapping characters).
The result is that essentially all rendering of proportional fonts
goes through that path.
Furthermore, for fixed fonts, XAA has scanline renderers that
each glyph width up to 32 pixels. The benchmark cases are written
in assembly. In this case it doesn't have to composite into a
scratch buffer. I renders directly to the target surface.
Note that with the Scanline CPUToScreenColorExpand routines,
XAA can render directly into your graphics engine's DMA command
buffer.
I don't think you'll be able to write non-AA code that
renders quicker than XAA, but you'll certainly risk rendering
it incorrectly.
For AA fonts you can hook the top level through XAAInfoRec.Glyphs.
If you don't provide that level XAA will provide one for you which
will optimize the 1 bit alpha glyphs, but will fall through to the
mi routines for everything else. Mi will composite the glyphs
into a single Picture and pass it through to the Composite operator
and you'll have another chance to accelerate it at that time.
XAA only provides two low-level Render-related primitives.
The "8 bit Alpha texture + color" and the "Generic color texture
composite" functions. It's difficult to abstract things much
beyond that since different graphics engines diverge quite a
bit at this level. XAA 3 (XFree86 5's XAA) doesn't even try.
It's only got the 8 bit alpha low-level primitive and everything
else is higher level where the driver is expected to do alot
more, though I suppose much of it could be offloaded to helper
functions.
Mark.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
