Gradients for Xrender

[Lars Knoll]

On Monday 30 May 2005 22:53, Keith Packard wrote:
> 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 guess it's a matter of definition if a linear gradient is fundamentally 
different from a radial one. (Mathematically the linear case is nothing else 
that the radial one with an infinite radius ;-)

But you are probably right, it's conceptually cleaner to separate them. The 
protocol stubs look and the API looks cleaner. Here's what I have running 
now:

renderproto.h:

typedef struct {
    CARD8	reqType;
    CARD8	renderReqType;
    CARD16	length B16;
    Picture	pid B32;
    xPointFixed p1;
    xPointFixed p2;
    CARD16      spread;
    CARD16      nStops;
} xRenderCreateLinearGradientReq;

#define sz_xRenderCreateLinearGradientReq                 28

typedef struct {
    CARD8	reqType;
    CARD8	renderReqType;
    CARD16	length B16;
    Picture	pid B32;
    xPointFixed center;
    xPointFixed focus;
    Fixed       radius;
    CARD16      spread;
    CARD16      nStops;
} xRenderCreateRadialGradientReq;

#define sz_xRenderCreateRadialGradientReq                 32

typedef struct {
    CARD8	reqType;
    CARD8	renderReqType;
    CARD16	length B16;
    Picture	pid B32;
    xPointFixed center;
    Fixed       angle; /* in degrees */
    CARD16 pad1;
    CARD16 nStops;
} xRenderCreateConicalGradientReq;

#define sz_xRenderCreateConicalGradientReq                 24


Xrender.h:

typedef struct _XLinearGradient {
    int spread;
    XPointFixed p1;
    XPointFixed p2;
} XLinearGradient;

typedef struct _XRadialGradient {
    int spread;
    XPointFixed center;
    XPointFixed focus;
    XFixed radius;
} XRadialGradient;

typedef struct _XConicalGradient {
    XPointFixed center;
    XFixed angle; /* in degrees */
} XConicalGradient;

Picture XRenderCreateLinearGradient (Display *dpy,
                                     const XLinearGradient *gradient,
                                     const XFixed *stops,
                                     const XRenderColor *colors,
                                     int nstops);

Picture XRenderCreateRadialGradient (Display *dpy,
                                     const XRadialGradient *gradient,
                                     const XFixed *stops,
                                     const XRenderColor *colors,
                                     int nstops);

Picture XRenderCreateConicalGradient (Display *dpy,
                                      const XConicalGradient *gradient,
                                      const XFixed *stops,
                                      const XRenderColor *colors,
                                      int nstops);

If it is required I can add the second radius for radial gradients as well.

> 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.

Got is running as well now with:

typedef struct {
    CARD8	reqType;
    CARD8	renderReqType;
    CARD16	length B16;
    Picture	pid B32;
    xRenderColor color;
} xRenderCreateSolidFillReq;

#define sz_xRenderCreateSolidFillReq                 16


Picture XRenderCreateSolidFill (Display *dpy,
                                const XRenderColor *color);

> > > 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.

Me neither. I just didn't want to break it now while testing.

> 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.

I have it all ready for kdrive. If we all agree, and someone gives me CVS 
access I can submit it ;-)

Cheers,
Lars