Bug 8614 - Render description shouldn't have dst_x, dst_y in composite_glyphs_{8,16,32}
Render description shouldn't have dst_x, dst_y in composite_glyphs_{8,16,32}
Status: NEW
Product: xorg
Classification: Unclassified
Component: Documentation
unspecified
All All
: high normal
Assigned To: Keith Packard
Xorg Project Team
2011BRB_Reviewed
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-12 03:19 UTC by Josh Triplett
Modified: 2011-10-06 10:14 UTC (History)
3 users (show)

See Also:


Attachments

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*

  http://keithp.com/~keithp/render/protocol.html

and the actual implementation

  http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob;f=renderproto.h
  http://gitweb.freedesktop.org/?p=xorg/lib/libXrender.git;a=blob;f=src/Glyph.c

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
2000-11-19.

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:

CompositeGlyphs8
CompositeGlyphs16
CompositeGlyphs32

        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

In
http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob;f=renderproto.h
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
http://gitweb.freedesktop.org/?p=xorg/lib/libXrender.git;a=blob;f=src/Glyph.c
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 
proto/renderproto/renderproto.txt

Comment 6 Jeremy Huddleston 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.