Bug 8614 - Render description shouldn't have dst_x, dst_y in composite_glyphs_{8,16,32}
Summary: Render description shouldn't have dst_x, dst_y in composite_glyphs_{8,16,32}
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Documentation (show other bugs)
Version: unspecified
Hardware: All All
: high normal
Assignee: Keith Packard
QA Contact: Xorg Project Team
Whiteboard: 2011BRB_Reviewed
Depends on:
Reported: 2006-10-12 03:19 UTC by Josh Triplett
Modified: 2011-10-06 10:14 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Josh Triplett 2006-10-12 03:19:59 UTC
Russell Shaw pointed out that our current descriptions of
xcb_render_composite_glpyhs_{8,16,32} lacks the INT16 dst_x and dst_y fields,
which should come immediately after the src_x and src_y fields.
Comment 1 Ian Osgood 2006-10-12 19:22:19 UTC
I disagree. I think this is a difference between the 2000 protocol *draft*


and the actual implementation


The confusion probably comes from the libXrender CompositeString methods, which have a pair of 
dst_x and dst_y parameters which are set into the first (and *only* the first) glyph element.  (BTW, even 
though the CompositeText methods also have dst parameters, they are *overridden* by the dst 
embedded in each element. I don't know whether this is a bug or not, but it is certainly an API wart.)

This certainly points out the need for some renderutil methods to wrap this mess.
Comment 2 russell shaw 2006-10-12 20:48:08 UTC
The doc at http://keithp.com/~keithp/render/protocol.html is Version 0.0.15 from

A more recent doc is from xorg-docs-X11R7.1-1.2/specs/Render/protocol, Version
0.9 2004-7-23. It also shows dst-x and dst-y:


        op:             PICTOP
        src:            PICTURE
        dst:            PICTURE
        mask-format:    PICTFORMAT or None
        glyphset:       GLYPHABLE
        src-x, src-y:   INT16
        dst-x, dst-y:   INT16           
        glyphcmds:      LISTofGLYPHITEM8        CompositeGlyphs8
        glyphcmds:      LISTofGLYPHITEM16       CompositeGlyphs16
        glyphcmds:      LISTofGLYPHITEM32       CompositeGlyphs32

all these structure names end with "Req", and are used with the GetReq()
function in Xlib. They appear to be the fixed (or non-variable length) part of
the messages.

Also, in
function XRenderCompositeString32(), there is:

if (nchar)
  nbytes = nchar * 4 + SIZEOF(xGlyphElt);
  BufAlloc (xGlyphElt *, elt, nbytes);
  elt->len = nchar;
  elt->deltax = xDst;
  elt->deltay = yDst;
  memcpy ((char *) (elt + 1), (char *) string, nchar * 4);

this shows xDst and yDst being sent with xRenderCompositeGlyphs8Req, but are in
the *variable-length* part of the message, and so are not in renderproto.h:

typedef struct {
    CARD8       reqType;
    CARD8       renderReqType;
    CARD16      length B16;
    CARD8       op;
    CARD8       pad1;
    CARD16      pad2 B16;
    Picture     src B32;
    Picture     dst B32;
    PictFormat  maskFormat B32;
    Glyphset    glyphset B32;
    INT16       xSrc B16;
    INT16       ySrc B16;
} xRenderCompositeGlyphsReq, xRenderCompositeGlyphs8Req,
xRenderCompositeGlyphs16Req, xRenderCompositeGlyphs32Req;
Comment 3 Jamey Sharp 2006-10-14 16:32:43 UTC
The RENDER extension, as implemented in the X.org reference server, has no dst-x
or dst-y fields in the CompositeGlyphs{8,16,32}. The English protocol
specification in xorg-docs says it does, however. I think the specification
should be corrected.
Comment 4 Daniel Stone 2007-02-27 01:34:01 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 5 Alan Coopersmith 2009-10-09 22:09:32 UTC
This bug is still present in the Render 0.11 spec in 

Comment 6 Jeremy Huddleston Sequoia 2011-10-06 10:14:54 UTC
I remember a slew of patches in this realm flying by on the list at some point 
in the past two years.  Has this been addressed and just not closed?   If it's 
still an issue, we should really fix it.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.