Re: Computing cairo surface dimensions in advance

[Daniel Elstner <daniel kitta googlemail com>]

Am Dienstag, den 12.12.2006, 19:58 -0500 schrieb Owen Taylor:
>
> > For instance, a strict reading of "if you change the transformation or
> > target surface" would suggest that cairo_translate() and cairo_move_to()
> > aren't equivalent wrt. pango_cairo_update_context().  In fact even the
> > cairosimple.c example seems to rely on cairo_move_to() to be safe.  What
> > happens if I move_to or translate by non-integer coordinates; is there a
> > difference in behavior?
> 
> Not currently. Yes that means if you have hinting on and render at
> non-integral coordinates, ink bounds can be up to half a pixel off.
> But that error isn't restricted to transformation-based positioning...
> pango_show_layout() also takes a position which could be non-integral.
> So, there's not much that can be done about it.

Okay.  This is important in my case since the position I move_to again
depends on the layout extents.

> The trouble with nailing it down, is that it can take away flexibility
> we need later - if we add cairo_surface_set_font_frobation_factor() and
> the application calls that, then it has to expect that Pango might
> take that into account when measuring layouts.
> 
> In other words we can define what are safe code patterns, but it's hard
> to define every unsafe pattern.

That's just fine with me.

> And yes, to be safe, you have to create a dummy 1x1 surface; currently
> if you take care that the values of:
> 
>  pango_cairo_context_set_font_options()
> 
> And
> 
>  pango_context_set_matrix();
> 
> are right then that's sufficient, and GTK+ relies on that, but we can't
> guarantee that will always be the case for every possible Cairo surface
> type.

Alright.  I'm glad to hear that at least the dummy surface hack is
sufficient.  Also, I reworked my code a little and made it reuse the
specially prepared context, so that it looks a lot less threatening now.

As to defining safe code paths, is it safe to say that no context update
is required if

  * the surface size changed but type and format are identical
  * the transformed position of every primitive drawn does not change
    except for a possible translation by an integer amount along either
    coordinate axis
?

I think that would be the amount of legalese required to allow for my
use case.  In my opinion it's worth to declare such usage safe, since
all the other ways to get out of the chicken'n'egg problem I can think
of border on the obscene.  One could try guessing until it fits, as with
those functions like strftime() that write into a fixed buffer but don't
tell you how large it'll need to be.  Yuck.  Please don't send me to
coder's hell.

Thanks for your clarifications,
--Daniel