[cairo] [PATCH] add extents to clone_similar

[Carl Worth]

On Thu, 5 Oct 2006 14:02:43 -0400, "Christopher \"Monty\" Montgomery" wrote:
> On 10/5/06, Owen Taylor <otaylor at redhat.com> wrote:
> > This is about the case where:
> >
> >  - You have a large image surface
> >  - You want to draw a small portion of it onto an Xlib surface
>
> Bingo.  Any case where a portion of an image surface is blitted to an
> xlib surface, although it obviously matters most for large ones.

I just added a performance test case (subimage_copy) to demonstrate
this bug. It copies a 4x4 chunk of an ever-larger image surface to the
destination. Notice that no matter how large the source and
destination surfaces are with the image backend, the running time is
constant:

[  0]    image-rgba      subimage_copy-16      0.009  0.15%   100
[  1]    image-rgba      subimage_copy-32      0.009  0.28%   100
[  2]    image-rgba      subimage_copy-64      0.009  0.05%   100
[  3]    image-rgba      subimage_copy-128     0.009  0.07%   100
[  4]    image-rgba      subimage_copy-256     0.009  0.04%   100
[  5]    image-rgba      subimage_copy-512     0.009  0.13%   100
[  0]    image-rgb       subimage_copy-16      0.010  0.00%   100
[  1]    image-rgb       subimage_copy-32      0.010  0.32%   100
[  2]    image-rgb       subimage_copy-64      0.010  0.31%   100
[  3]    image-rgb       subimage_copy-128     0.009  0.00%   100
[  4]    image-rgb       subimage_copy-256     0.010  0.36%   100
[  5]    image-rgb       subimage_copy-512     0.009  0.12%   100

Contrast that to the bad scaling exhibited by the xlib backend:

[  0]     xlib-rgba      subimage_copy-16      0.081  0.44%   100
[  1]     xlib-rgba      subimage_copy-32      0.093  0.30%   100
[  2]     xlib-rgba      subimage_copy-64      0.149  0.45%   100
[  3]     xlib-rgba      subimage_copy-128     0.230  1.72%   100
[  4]     xlib-rgba      subimage_copy-256     1.127  1.71%   100
[  5]     xlib-rgba      subimage_copy-512     5.159  1.62%   100
[  0]     xlib-rgb       subimage_copy-16      0.118  0.46%   100
[  1]     xlib-rgb       subimage_copy-32      0.159  0.90%   100
[  2]     xlib-rgb       subimage_copy-64      0.337  1.14%   100
[  3]     xlib-rgb       subimage_copy-128     0.872  3.33%   100
[  4]     xlib-rgb       subimage_copy-256     3.918  1.60%   100
[  5]     xlib-rgb       subimage_copy-512    15.103  2.31%   100

[Aside: I'm not sure why the xlib-rgb case is 3 times slower than the
xlib-rgba case. The difference between these is that in the xlib-rgba
case the destination is a depth-32 pixmap while in the xlib-rgb case
the destination is a DefaultDepth window. So, when we're doing our
costly copying to an intermediate xlib surface, we may be doing it to
a pixmap of a different depth in each case, but it should be a pixmap
either way. Why should the X server be 3 times slower about copying in
one case compared to the other?]

And here are the xlib results after applying the updated version of
the patch, (after fixing up the corruption from email as well).

[  0]     xlib-rgba      subimage_copy-16      0.079  0.50%   100
[  1]     xlib-rgba      subimage_copy-32      0.079  0.35%   100
[  2]     xlib-rgba      subimage_copy-64      0.083  0.46%   100
[  3]     xlib-rgba      subimage_copy-128     0.081  0.28%   100
[  4]     xlib-rgba      subimage_copy-256     0.082  0.40%   100
[  5]     xlib-rgba      subimage_copy-512     0.082  0.26%   100
[  0]     xlib-rgb       subimage_copy-16      0.123  0.47%   100
[  1]     xlib-rgb       subimage_copy-32      0.155  0.82%   100
[  2]     xlib-rgb       subimage_copy-64      0.271  3.45%   100
[  3]     xlib-rgb       subimage_copy-128     0.730  1.50%   100
[  4]     xlib-rgb       subimage_copy-256     2.579  1.64%   100
[  5]     xlib-rgb       subimage_copy-512    10.157  2.52%   100

So everything's faster now, and the xlib-rgba cases are showing the
constant performance scaling we'd like to see. The xlib-rgb cases
improved but still have some badness in them. This suggests that the
difference I pointed out above must be due to some additional
full-surface copying badness in addition to the bug that this patch
fixes.

Monty, want to chase down this new bug as well? ;-)

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061005/e4985400/attachment.pgp