Gradients for Xrender

[Keith Packard]

On Mon, 2005-05-30 at 22:33 +0200, Lars Knoll wrote:

> > I think I'd rather see this use a new request for each gradient type;
> > overriding operands doesn't seem necessary, and that way I think the
> > client API will be less error-prone.
> 
> I thought about this, and decided, that three requests might be overkill. The 
> data to transport over the wire is pretty similar. One could maybe add 3 
> methods in the client API if one would want to go for full typesafety, but I 
> don't see this as a big problem.

Extra requests are appropriate when the values are used for
fundementally different things.  If they were just absolute vs relative
values then I'd agree with a single request.

I'd like to keep the Xrender API as close to the protocol as possible,
so if we think we need three functions in the API, then we should have
three requests in the extension.


> That's on my list as well. I'd love to be able to have support for compressed 
> images in the server. But there the easiest way could be to tie them to a 
> Drawable.

Hmm.  I'm not sure we should tie them to a drawable; that makes them
more obviously RGB images and not something like YUV.  But, the notion
of a virtual Picture object that you can pump data into makes some
sense; one issue with a pure PutImage model is that MaxRequest gets in
the way of seamless operations on large images.

> I also thought about adding support for Solid fills that do not require a 
> drawable (XRenderCreateSolidFill), but since a solution using Drawables exist 
> it was less of a priority to me. I could easily add it though; it would 
> probably make the Render API a bit more complete and easier to use.

Oh, that's an obvious addition to the gradients, and makes Render look a
whole lot more like cairo :-)

Let's do that too.

> > Let's figure out what the right interface is and we can bump the Render
> > minor protocol number and get the code into CVS.
> 
> Sounds good. The code will need some work to make it into Xorg as well. 
> Currently I made sure we don't go through the acceleration hooks if we have a 
> gradient somewhere, as some drivers could crash if they find a 0 Drawables on 
> a Picture, but in the long term one would want to pass them through and let 
> the driver decide if it wants to handle the gradient in hardware.

I wouldn't bother doing any DIX-level request filtering; we can assume
that the DDX manages the whole thing.  And, the same thing at the kdrive
KAA level -- pass the stuff down to the driver and let those few (Xati)
drivers which do accelerate Render operations get fixed.  I'm not afraid
of internal X server API changes at all, even non-backward compatible
ones.

Doing this in kdrive first should give us plenty of opportunity to see
if it's the right abstraction, and whether we need other Render changes
to cover these synthetic pictures.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050530/4a8b614d/attachment.pgp>