[Xcb] XRenderCompositeString32
Josh Triplett
josh at freedesktop.org
Thu Oct 12 03:22:49 PDT 2006
Russell Shaw wrote:
> Vincent Torri wrote:
>>
>> On Thu, 12 Oct 2006, Russell Shaw wrote:
>>
>>> Hi,
>>> In XRender.h, we have:
>>>
>>> void
>>> XRenderCompositeString32 (Display *dpy,
>>> int op,
>>> Picture src,
>>> Picture dst,
>>> _Xconst XRenderPictFormat *maskFormat,
>>> GlyphSet glyphset,
>>> int xSrc,
>>> int ySrc,
>>> int xDst,
>>> int yDst,
>>> _Xconst unsigned int *string,
>>> int nchar);
>>>
>>>
>>> In xcb/render.h, we have:
>>>
>>> xcb_void_cookie_t
>>> xcb_render_composite_glyphs_32_checked (xcb_connection_t *c,
>>> uint8_t op,
>>> xcb_render_picture_t src,
>>> xcb_render_picture_t dst,
>>> xcb_render_pictformat_t mask_format,
>>> xcb_render_glyphset_t glyphset,
>>> int16_t src_x,
>>> int16_t src_y,
>>> uint32_t glyphcmds_len,
>>> const uint8_t *glyphcmds)
>>>
>>>
>>> In xcb_render_composite_glyphs_32_checked(), shouldn't there be "const
>>> uint32_t *glyphcmds" instead of "const uint8_t *glyphcmds" ?
>>>
>>> It is misleading, because glyphcmds_len could be mistaken for the byte
>>> length instead of the number of uint32_t elements.
>>
>> I think that you are right (http://keithp.com/~keithp/render/protocol.html)
>>
>> I also think that there is the same error for xcb_render_composite_glyphs_16.
>
> The params dst_x and dst_y are also missing. I made a patch.
Thank you very much for reporting this. The lack of dst_x and dst_y
definitely constitutes a bug in our description of the Render extension,
which becomes a bug in the generated stubs. I've filed this as bug 8614
at https://bugs.freedesktop.org/show_bug.cgi?id=8614 so we don't lose
track of it, added you to the CC list for that bug, and made that bug a
blocker of the 1.0 release.
However, the use of uint8_t (aka "BYTE") does not actually constitute a
bug here, and glyphcmds_len *does* represent the byte length. We did
this intentionally, because each item in "glyphcmds" can represent
either a GLYPHELT32 (which has x, y, and a variable-length list of
glyphs) or a GLYPHABLE (either a GLYPHSET or a FONTABLE). This means
that the elements of the list "glyphcmds" have varying lengths, and thus
a C array plus length cannot correctly represent them. (The previous
description of this request, based on the extension documentation, just
plain didn't work.) Thus, you need to construct an appropriate list of
bytes and pass it to the function. In the future, we may supply a set
of functions to construct such a list of bytes by incrementally adding
GLYPHELTs or GLYPHABLEs, and do similarly for other requests with lists
of variable-length types.
You may want to look at the recent thread 'Anyone ever used
"XCBRenderCompositeGlyphs"', started by Yang Jianjun on 10/11/2006,
which discusses this same issue, as well as the bug report
https://bugs.freedesktop.org/show_bug.cgi?id=8602; as pointed out in
that thread and report, you may want to wait for us to implement the
higher-level "xcb_renderutil_composite_string_{8,16,32}" functions,
rather than directly using the underlying protocol requests via XCB,
which do not do exactly the same thing as the Xrender functions you want.
- Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20061012/e31c9e92/signature.pgp
More information about the Xcb
mailing list