Bug 32014

I can confirm this bug.  I have the same problem and it is resolved by downgrading cairo to 1.8.10.

I have the same problem. Downgraded Cairo to 1.8.10 too.

This appears to be due to having 'display->buggy_repeat' set in _cario_xlib_device_create(). NX (3.5, at least) presents itself as an X.Org server with version 60900000, which trips the 'buggy_repeat' flag. 

'buggy_repeat' is set on X.Org 6.9 to avoid a bug which will crash the X server. On NX 3.5, running the 'extend-reflect' test case after forcing the buggy_repeat flag to FALSE on git rev ced061124d0b402c did not crash the X server, so it is possible this bug does not need to be worked around on NX servers. (The test application crashes on svg11 and svg12 test modes, and fails on others, but it doesn't crash the X server itself. Plus, NX fails many other tests, and other tests *will* crash the server; not exactly a bastion of correctness.)

Cairo will use software compositing for some operations, preventing NX from doing its X11 protocol compression magic to send text in an efficient manner. The commit indicated by Ryan Prichard causes more operations than before to use software compositing. I'm not sure if this was intentional or not.

I see three reasonable solutions:

* Get NoMachine to update NX's reported version number. My current employer makes extensive use of NX; I'll try to have someone talk to them about this.

* Detect and whitelist NX for buggy_repeat using an out-of-band mechanism.

* Revert to the (possibly incorrect?) stricter test for falling back to software rendering.

In the mean-time, users can apply this patch to Cairo to work around the workaround. I'm not recommending that this patch be applied to Cairo itself, it's just for NX users who can't stand the slowness. Applies to current git HEAD, but probably works fine with 1.10 too.

diff --git a/src/cairo-xlib-surface.c b/src/cairo-xlib-surface.c
index f8caf83..ffaa344 100644
--- a/src/cairo-xlib-surface.c
+++ b/src/cairo-xlib-surface.c
@@ -1994,8 +1994,8 @@ _recategorize_composite_operation (cairo_xlib_surface_t         *dst,
            return DO_XTILE;
     }
 
-    if (dst->buggy_repeat && src_attr->extend == CAIRO_EXTEND_REPEAT)
-       return DO_UNSUPPORTED;
+    //if (dst->buggy_repeat && src_attr->extend == CAIRO_EXTEND_REPEAT)
+       //return DO_UNSUPPORTED;
 
     if (! CAIRO_SURFACE_RENDER_HAS_COMPOSITE (src))
        return DO_UNSUPPORTED;

(In reply to comment #3)
> This appears to be due to having 'display->buggy_repeat' set in
> _cario_xlib_device_create(). NX (3.5, at least) presents itself as an X.Org
> server with version 60900000, which trips the 'buggy_repeat' flag. 
> 
> 'buggy_repeat' is set on X.Org 6.9 to avoid a bug which will crash the X
> server. On NX 3.5, running the 'extend-reflect' test case after forcing the
> buggy_repeat flag to FALSE on git rev ced061124d0b402c did not crash the X
> server, so it is possible this bug does not need to be worked around on NX
> servers. (The test application crashes on svg11 and svg12 test modes, and fails
> on others, but it doesn't crash the X server itself. Plus, NX fails many other
> tests, and other tests *will* crash the server; not exactly a bastion of
> correctness.)
> 
> Cairo will use software compositing for some operations, preventing NX from
> doing its X11 protocol compression magic to send text in an efficient manner.
> The commit indicated by Ryan Prichard causes more operations than before to use
> software compositing. I'm not sure if this was intentional or not.
> 
> I see three reasonable solutions:
> 
> * Get NoMachine to update NX's reported version number. My current employer
> makes extensive use of NX; I'll try to have someone talk to them about this.
> 
> * Detect and whitelist NX for buggy_repeat using an out-of-band mechanism.
> 
> * Revert to the (possibly incorrect?) stricter test for falling back to
> software rendering.

Another (untested) possibility is to use the xlib-xcb functions.
Is NX sluggish on a cairo library compiled with --enable-xlib-xcb ?

> 
> In the mean-time, users can apply this patch to Cairo to work around the
> workaround. I'm not recommending that this patch be applied to Cairo itself,
> it's just for NX users who can't stand the slowness. Applies to current git
> HEAD, but probably works fine with 1.10 too.
> 
> diff --git a/src/cairo-xlib-surface.c b/src/cairo-xlib-surface.c
> index f8caf83..ffaa344 100644
> --- a/src/cairo-xlib-surface.c
> +++ b/src/cairo-xlib-surface.c
> @@ -1994,8 +1994,8 @@ _recategorize_composite_operation (cairo_xlib_surface_t  
>       *dst,
>             return DO_XTILE;
>      }
> 
> -    if (dst->buggy_repeat && src_attr->extend == CAIRO_EXTEND_REPEAT)
> -       return DO_UNSUPPORTED;
> +    //if (dst->buggy_repeat && src_attr->extend == CAIRO_EXTEND_REPEAT)
> +       //return DO_UNSUPPORTED;
> 
>      if (! CAIRO_SURFACE_RENDER_HAS_COMPOSITE (src))
>         return DO_UNSUPPORTED;

It certainly seems to have an effect - reliable server crash when launching GEdit with git rev ced061124d0b402c is compiled with --enable-xlib-xcb (binary loaded via LD_LIBRARY_PATH, so crash is probably not gedit-specific). I can try to scrounge up additional information if it's needed here, but with NX being quasi-closed-source it may not be easy or helpful to do so.

Although it does end up crashing *very* quickly, so it solves the performance problem in one sense.

(In reply to comment #5)
> It certainly seems to have an effect - reliable server crash when launching
> GEdit with git rev ced061124d0b402c is compiled with --enable-xlib-xcb (binary
> loaded via LD_LIBRARY_PATH, so crash is probably not gedit-specific). I can try
> to scrounge up additional information if it's needed here, but with NX being
> quasi-closed-source it may not be easy or helpful to do so.

A server crash should never happen, no matter what the application does.
If it is easy to reproduce, it might be an useful bugreport for NX developers.

> 
> Although it does end up crashing *very* quickly, so it solves the performance
> problem in one sense.

NX developers have been informed : 

   http://www.nomachine.com/tr/view.php?id=TR01J02646

The quick-fix patch suggested in comment #3 resolved the issue for me in Ubuntu 11.10.  I applied the patch against Ubuntu's cairo source package 1.10.2-6ubuntu3 (the offsets had to be adjusted a bit).

I'm having trouble applying this patch to libcairo2 version 1.13.0 from Ubuntu 14.04

Doing some tracing, it looks like display->buggy_repeat is accessed by the function:

cairo_bool_t
_cairo_xlib_display_has_repeat (cairo_device_t *device)
{
    return ! ((cairo_xlib_display_t *) device)->buggy_repeat;
}

However, I don't see that function called anywhere else in the code.

I'm still observing slowness for GTK programs using NX (both nx2go and NoMachine).

Could anyone comment on the proper patch for libcairo2 version 1.13.0?

I'm also having trouble locating the callers of _recategorize_composite_operation.  Perhaps I have an incomplete source tree?
$ find -type f | xargs grep recategorize_composite
./cairo-xlib-render-compositor.c:    operation = _recategorize_composite_operation (dst, op, src, &src_attr,
./cairo-xlib-render-compositor.c:    operation = _recategorize_composite_operation (dst, op, src,

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/290.