[Xcb] Carbon, the new xcb based terminal emulator.

[Simon Gomizelj]

Okay, first, sorry Peter for the double post. I failed at using a mailing
list, please forgive me, its my first time.

Oh wow. I did not expect this kind of response to my question. First of all,
thank you Jamey Sharp, that answered my question exactly.

Thank you everyone else for their input, I've found this read to have
been extremely enlightening and educational. There is much good information
here I will take under consideration.

Carbon, by design, is going to support both core fonts and xft. I want it to
mirror urxvt in features and be similarly small and light, and thats all
that urxvt provides. I'm implementing core font support first because thats
how I use urxvt myself as I don't need unicode. Right now its only slightly
"heavier" then suckless' st project (heavier meaning modular), and thats all
I'm aiming for, really.

Now, urxvt recommends turning off xft support unless you need unicode
because core fonts are so much faster. I understand using core fonts
directly isn't exactly the most modern of techniques, but for a terminal
emulator dealing with monospaced fonts, its fast and light and does the job
well. I understand ram and processor power is plentiful these days, but I
can't help but feeling pango is overkill. Why waste cpu cycles when
something more interesting can?

I understand now that there's a performance hit in querying a font, but it
does only need to be done once. The font is queried at the start to
determine a max character height and width and that information is used to
build a "grid" of characters on screen. In my practice implementation of xcb
core text rendering I got monospaced output of the contents of a text file
rendered to screen in just over 100 lines. Sure it doesn't do unicode, but
its simple and fast. Why complicate things with pango?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100311/4449f636/attachment.html>