Re: Re:FW: XFree86 future

On Sun, 2003-03-23 at 08:58, Alan Cox wrote:
> >  - Applications are getting closer and closer to the  point where all
> >    rendering is via RENDER, but RENDER isn't optimized,
> >    even ignoring acceleration. Fairly small amounts of work on
> >    the software layer could make RENDER many times faster than it
> >    is currently.
> 
> Do you have good data on which subset of render is used a lot ? Which
> bits need to be optimised for example ?

GTK+ uses a pretty small subset:

 A) Text drawing - compositing a solid opaque color through a 
    1 channel alpha (or 4 channel) alpha mask onto a x888 or
    565 destination.

 B) Image drawing - GTK+ does this a little "strangely" - it 
    uses the same image as both source and mask to represent
    non-premultiplied alpha.

    So, it would be nice to have special-code for handling
    x888 image and 8xxx mask pointing at the same apps.

    Other apps will simply want 8888 image without mask to
    be fast.

Text drawing is considerably more important than image drawing.
Basically there is a very small subset of the full RENDER
space that is used currently, it's well known how to make
these operation fast (or with MMX, very fast), there is just
a need for some infrastructure for choosing the right
optimized code paths.

There is also the major problem right now that if you have sufficient
video ram but no HW compositing, X will be doing framebuffer _reads_
to alpha composite. (And for 16bpp color, 16 bit framebuffer reads
at that.) There are various solutions here at varying levels
of complexity. Most simply, a way for GTK+ to say "if you don't
have HW render, don't put this pixmap into video RAM" would work
fine.

Regards,
                                         Owen