EXA and migration [was: shrink xrender featureset]

[Stephane Marchesin]

On Wed, Nov 26, 2008 at 10:09, Michel Dänzer
<michel at tungstengraphics.com> wrote:
> On Wed, 2008-11-26 at 06:48 +1000, Dave Airlie wrote:
>>
>> Yeah I'm with this, EXA really needs optimisations that know you have composite,
>> and just to render the stuff with the CPU and composite it on. Generally it does
>> stupid things like fill on the GPU, then render with CPU then composite.
>
> We've mostly fixed the cases where this was done within the EXA core[0].
> Unfortunately, such pathological behaviour can also originate from the
> client side. A while ago, I expressed an idea of deferring solid fills
> until it's known whether the next operation on a pixmap is done by the
> GPU or CPU, and doing the fill using the same. Maybe something like that
> could be an interesting project for someone interested in improving EXA,
> as opposed to just ranting about it.
>
>
> [0] I only know of a potential such case left in exaGlyphs, if the
> driver can't render to A8. If you know of others, please do bring them
> up - can't fix problems you don't know about...
>

Repeat modes are another offender here. They could probably be
emulated in core EXA though...

But really, at the core the problem is that xrender is exposing the
same feature in multiple ways. For example, if you want to draw a
gradient, you can either have a 500x1 pixmap and stretch it, or have a
500x1 pixmap and repeat it. With the same result, except the fallbacks
will be different from one driver to the other. What's an application
developer supposed to do then ?

Stephane