[Xcb] XRenderCompositeString32

[Russell Shaw]

Ian Osgood wrote:
> 
> 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.

But *I* do;)

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

Which i do. I use XRenderCompositeString32.

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

One thing i totally object to is having multiple hidden backend executions
paths, where the path that is taken is not obvious to the developer or user.

Too many times i've used some gtk/cairo/xft/pango thing and have wondered why
a 1GHz+ pc goes at a snails pace. Part of the blame is with X itself. I found
that xinerama makes things *much* slower than mergedFB, only i found that out
by accident after *2 years*.

There is currently *no* GUI text layout system that meets my performance
standards, and i've already ruled out using Xft.

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

I just realized today that even though XRenderCompositeString/Text/8/16/32
don't take per-glyph kerns in the glyph strings you give them, you can
give per-string kerns to XRenderCompositeText/8/16/32, where each string
has only one glyph.

I'm only using XRender text functions temporarily because they're barely
adequate.

I'll add a much better glyph-management extension when i get around to it.