Hi Karl,

I don't see what you're hoping to get out of the cairo bug report here.

I looked through the (long) GNOME bugzilla thread on this issue before
I could get any sense of what the issue is at all.

And what I *finally* got was:

    cairo_set_set_source_surface (cr, non_integer_X, non_integer_Y);
    cairo_paint (cr);

Is slow for some particular combinations of X servers/drivers.

I don't doubt that for a second, but I don't see what change could
happen in cairo to fix the issue.

Obviously, the ideal thing long-term is to fix the X drivers in all
cases so that compositing a surface with a transformation more
sophisticated than integer-translation-only is fast.

In the meantime, you have various workarounds possible in your
application, all of which were mentioned in the bugzilla entry:

   * Use integer translations

   * Force software-rendering by using cairo_image_surface and then
     copying only the final result.

Is there anything that you can see that we could change in cairo to
help here? I'm not seeing anything obvious.

Thanks,

-Carl

Hi Carl,

> I don't see what you're hoping to get out of the cairo bug report here.

Well I was hoping that the long term fix you mentioned in the X drivers would be duly noted and happen some day. That is all, so this was just meant as a placeholder. 

> I looked through the (long) GNOME bugzilla thread on this issue before
> I could get any sense of what the issue is at all.
> 
> And what I *finally* got was:
> 
>     cairo_set_set_source_surface (cr, non_integer_X, non_integer_Y);
>     cairo_paint (cr);
> 
> Is slow for some particular combinations of X servers/drivers.
> 
> I don't doubt that for a second, but I don't see what change could
> happen in cairo to fix the issue.
> 
> Obviously, the ideal thing long-term is to fix the X drivers in all
> cases so that compositing a surface with a transformation more
> sophisticated than integer-translation-only is fast.
> 
> In the meantime, you have various workarounds possible in your
> application, all of which were mentioned in the bugzilla entry:
> 
>    * Use integer translations
> 
>    * Force software-rendering by using cairo_image_surface and then
>      copying only the final result.
> 
> Is there anything that you can see that we could change in cairo to
> help here? I'm not seeing anything obvious.

Thanks to Jorgen I've managed to see the bug, and his patch works well enough for me to apply it to GNOME system monitor (with a bity of clean up and some slight fixes) so I think tonight I'll go with that fix and hope that we can still get this into the next release. Although it may be a point release update.

Thanks for your insight, and confirmation of the issue we're facing and the possible fixes.

- Karl

If the source surface is using FILTER_NEAREST, then cairo could convert the offset to an integer translation and ensure the fast path is hit (as noted in the TODO). But I am at a loss as to what further can be achieved by keeping this bug open.

commit 3eb4bc37577e905d93a1935e7a9cd33ae8dbda15
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Oct 13 23:26:04 2008 +0100

    [pattern] Optimize away fractional translation for NEAREST patterns.
    
    As identified in bug 15479,
      Unpredictable performance of cairo-xlib with non-integer translations of a
      source surface pattern
      (https://bugs.freedesktop.org/show_bug.cgi?id=15479),
    source surfaces with a fractional translation hit slow paths for some
    drivers, causing seemingly random performance variations. As a work-around
    Owen Taylor proposed that cairo could convert non-integer translations on
    NEAREST sources patterns to their integer equivalents.
    
    The messy detail involved here is replicating the rounding mode used by
    pixman for the sample offset, but otherwise the conversion is fairly
    trivial.