[cairo] misc. cairo_t questions

[Uli Schlachter]

Hi,

On 12.04.2012 19:50, Roger Davis wrote:
[...]
> (1) My first question is relating to optimal usage of cairo_t context objects
> in terms of performance and any other issues which might be of concern.
> My existing Xlib drawing code utilizes many (a few dozens of) GCs to draw
> to off-screen Pixmap objects with various foreground colors, line widths,
> etc. GCs are relatively inexpensive objects in Xlib-land, can I assume that
> cairo_t objects are similarly cheap for cairo drawing?
[...]

You are right GCs are inexpensive. In fact, they are so inexpensive that I
wonder why you are optimizing their use.

Cairo contexts (cairo_t) are inexpensive, too. Usually, one creates a cairo_t
whenever one needs one and then throws it away when done. Compared to these,
caching cairo_ts sounds overly complex to me, but that might just be me.

[...]
> From the contrary
> perspective, is there anything expensive going on within calls such as
> cairo_set_source_rgb() and cairo_set_line_width(), which will be the primary
> points of variation within my context objects, or are these trivial
> low-overhead functions which just set a couple of structure fields?

cairo_set_line_width() really just sets a structure field (after some
indirection). cairo_set_source_rgb() is a little more complex. However, the
usual hot path while rendering is the actual rendering. If you manage to be slow
due to changing the source color, you are doing something weird.

> On a related note, it appears that there is no way that the same cairo_t
> can be used to target different surface objects in the same way that a
> single Xlib GC can be used to write to multiple Xlib Pixmaps as long as they
> are of the same depth, etc.

This is correct. If you want to draw to another surface, create another cairo
context.

[...]
> (2) Despite being denigrated as a toy API, the cairo_text...() functions
> really do seem adequate for my needs. Is this API intended to be stable,
> or is it risky to place my faith in it with regard to it remaining a part
> of cairo (or not) for the foreseeable future?

I bet that this will stay part of cairo's API for quite a while. As long as you
just intend to display English text, this API might be good enough for you. But
as soon as internationalization becomes an issue, you will want something like
Pango.

> (3) It seems like almost all of the cairo_set...(), etc., functions return
> void. Is there a standard behavior in place to handle bad arguments to these
> calls, or other error conditions?

Yes. If some object gets in an error condition, this error condition is sticky.
You can not un-error something afterwards. To get this error flag, there are
cairo_status(), cairo_surface_status(), cairo_pattern_status(), ....

> Many of these functions seem unlikely to
> fail due to anything other than gross stupidity, e.g., cairo_set_source_rgb(), 
> but a call like cairo_select_font_face(cr, "MyNonexistentFont" ...) would
> seem a bit different in this regard, with its failure resulting in something 
> unpredictable. How can one check for errors from such calls or, if that's 
> not possible, what kind of behavior can be expected in the event of failure?

cairo_select_font_face() doesn't fail* either. The specified family is more
meant as a hint and if no exact match is found, it will fall back to something
else. Welcome to the toy font API.

Cheers,
Uli

*Well, yes, you can make cairo_select_font_face() fail by providing an invalidly
encoded family name or invalid enum values. But that's only really doable on
purpose.
-- 
- He made himself, me nothing, you nothing out of the dust
- Er machte sich mir nichts, dir nichts aus dem Staub