Re: Computing cairo surface dimensions in advance

[Owen Taylor <otaylor redhat com>]

On Wed, 2006-12-13 at 00:57 +0100, Daniel Elstner wrote:
> Am Dienstag, den 12.12.2006, 15:07 -0500 schrieb Behdad Esfahbod: 
> > On Mon, 2006-12-11 at 17:35 -0500, Daniel Elstner wrote:
> > > 
> > > 'Tis ain't pretty.  Is the code above actually correct?  Is there a
> > > better to do this kind of thing?
> > 
> > What you say is basically correct.  Currently you first need to create a
> > tiny surface to measure a PangoLayout before you create your final
> > surface.  Any suggestions how to improve this?
> 
> Tough one, as I don't think I understand all of the implications yet.
> It'd help a lot if the documentation of pango_cairo_update_context()
> would elaborate a little on when and why it needs to be called, and shed
> some light on the corner cases.
> 
> 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.

> >From my limited understanding, the update after changing the target
> surface is necessary because hinting might be done differently, like
> when switching from subpixel AA on the screen to an image surface in
> memory with only an alpha channel.  And wrt. transformation, an update
> would be in order whenever there are changes to the fractional part of
> any used coordinate after transformation.

Right now the only thing that is going to matter is if you change the
scale/rotation/shear of the matrix. And not even then. (There is 
generally going to be no difference between a rotation of 5 degrees
and one of 37 degrees. But 5/37 is going to be different than 0/90
degrees.

> If these were really the only cases requiring an update then it could be
> stated that integer transformations with unchanged surface type are safe
> to use without pango_cairo_update_context().  But I reckon that there
> are more restrictions necessitating the update.  Still, even if a
> blanket statement like that isn't possible it'd be great if the
> requirements were stated more clearly.  For instance, right now the
> documentation doesn't really allow for changing the target the surface
> at all, even if its type stays the same.

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.

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.

					- Owen