[Xcb] XRenderCompositeString32

[Ian Osgood]

On Oct 12, 2006, at 9:17 AM, Russell Shaw wrote:

> Josh Triplett wrote:
>> Russell Shaw wrote:
>>> Vincent Torri wrote:
>>>
>>>> On Thu, 12 Oct 2006, Russell Shaw wrote:
>>>>
> ...
>
>>> 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.
>
> Hi,
> I studied XRenderCompositeString8/16/32 some time ago and concluded  
> they
> are fatally flawed, because they don't take per-glyph kernings.  
> Instead,
> i just render strings *one* glyph at a time, so each character can get
> its own kerning. I won't use any higher-level string functions in  
> xcb unless
> they also take per-glyph kernings.

Yes, the CompositeString functions are for simpleminded rendering
(one glyph set, no kerning). You should use the CompositeText
functions if you want to switch fonts, kern, or adjust baseline between
characters in a single request.

It seems no-one uses CompositeString/Text directly. You need a whole
raft of code to 1) load glyphs from font files, 2) render glyphs, 3)  
manage
a glyph cache, 4) format the data in the CompositeGlyphs request  
correctly.
The Xft or cairo libraries most of this work for you. An XCB cairo  
backend
is already underway; perhaps it is time to start on a port of Xft to  
use the
XCB library as well.  I'm not sure how else we'll be able to test any
renderutil wrappers we end up writing for CompositeGlyphs.

It is kind of embarrassing how little text support the X protocol  
provides.

Ian