[cairo] invalid size error, nth ping

[Behdad Esfahbod]

Paolo Bonzini wrote:
>> I'll pull these later. Thanks.
> 
> Thanks!
> 
>>> Commentary on my cache branch, as usual, would also be nice. :-)
>> I'll take another look since once again I'm in a situation where some
>> internal caching of server-side resources would be useful. However the
>> question remains is this Cairo's responsibility? We provide a similar
>> surface so that the application can cache as much as it deems necessary,
>> what further mechanism should Cairo possess? Anyway I promise to look at
>> your caching infrastructure again and see if helps with my problem. ;-)
> 
> Yes, the problem (even before discussing the API) is whether it is
> needed at all.  I think there is some contrast between the backend
> people and the device-independent people on this.
> 
> While it's true that cairo_surface_create_similar often simplifies the
> creation of cached representations, I find that suboptimal.  Code like
> this (from cairogears, the cairo-glitz canonical demo; but it would
> apply anyway to any other demo):
> 
>     cairo_surface_t *image_surface;
>     image_surface = cairo_image_surface_create_from_png (name);
>     if (cairo_surface_status (image_surface))
>         return image_surface;
> 
>     *width = cairo_image_surface_get_width (image_surface);
>     *height = cairo_image_surface_get_height (image_surface);
> 
>     {
>         cairo_surface_t *glitz_surface;
>         cairo_t *cr;
> 
>         glitz_surface = cairo_surface_create_similar (
>                  cairo_get_target (glitz_target),
>                  CAIRO_CONTENT_COLOR_ALPHA,
>                  *width, *height);
> 
>         cr = cairo_create (glitz_surface);
>         cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
>         cairo_set_source_surface (cr, image_surface, 0.0, 0.0);
>         cairo_paint (cr);
>         cairo_destroy (cr);
>         cairo_surface_destroy (image_surface);
>         return glitz_surface;
>     }
> 
> is plain ugly, but using image surfaces directly has a 10x performance
> penalty.  Everything in the braces could be replaced simply by
> 
>     cairo_image_surface_set_cacheable (image_surface,
> 				       CAIRO_CACHE_ENABLE_AUTO);
>     return image_surface;
> 
> and still have the same performance.

Hi Paolo,

I actually like the simplicity!  I think I can even be tempted into liking it
if the names are improved ("set_cacheable", ugh!).  However, first question
is, can or can't we do that automatically?  Cairo should just work.  Why
doesn't user have to give us that information to begin with?  We already
automagically cache glyphs and solid pattern surfaces on the server.  Sure
it's not that different.

Cheers,
behdad


>>> I also have some patches to glitz.git with bugfixes, added documentation
>>> and examples, support for 64-bit Mac OS and Cocoa, etc.; how can I get
>>> them integrated?  These are at
>>> http://www.inf.unisi.ch/~bonzini/webdav/glitz.git in branch master.
>> Who is responsible for glitz now?
> 
> Nicolas Bruguier was named responsible, but there were problems granting
> him access to glitz.git.  Also, I haven't heard from him in the last month.
> 
>> There's no shortage of good ideas in
>> there - though not everything looks ideal for a i915 sadly. But it would
>> be a shame to let it simply bitrot away, especially as we have people
>> interested in using and fixing up cairo/glitz once more. It currently
>> belongs to the xorg group - could we add a glitz group and start to add
>> new maintainers/developers?
> 
> That would be great.  For me it would be enough to get a freedesktop.org
> so that I can publish my branches in a "more official" place (and with a
> more stable URL).
> 
> Paolo
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>