[IDEA] shrink xrender featureset

John Tapsell johnflux at gmail.com
Mon Nov 24 02:20:07 PST 2008


2008/11/23 Eric Anholt <eric at anholt.net>:
> On Sat, 2008-11-22 at 18:19 +0100, Maarten Maathuis wrote:
>> Currently there exist several operations in xrender that are better
>> off client side or through some other graphic api (imo). Think of
>> trapezoid rasterisation, gradient rendering, etc. Doing this stuff
>> client side avoids unforseen migration issues and doesn't create any
>> false impressions with the api users.
>>
>> My suggestion would be to deprecate everything, except solid,
>> composite, cursor stuff and glyphs. The idea is to stop doing
>> seemingly arbitrary graphics operations that end up causing slowness
>> most of the time (if not worked around "properly"). At this stage
>> noone accelerates these operations, so there can be no complaints
>> about that.
>>
>> xrender is here to stay, but there are limits to it, so let's accept
>> this and move on (for other needs).
>>
>> How do others feel about this?
>
> NAK.  We'll be building gradients support soon.  It's a required
> feature, doable in a shader, and software isn't good enough.
>
> Traps we don't have a concrete plan on yet, but given how widely used
> they are they certainly can't be deprecated.  Back when I last touched
> EXA the migration for them was handled, anyway.

Out of interest - how widely are gradients used?  How often will a
typical desktop use gradients?

John



More information about the xorg mailing list