GTK programs in Ubuntu 10.10 are sluggish over NX

Bug #682338 reported by Ryan Prichard on 2010-11-28
46
This bug affects 7 people
Affects Status Importance Assigned to Milestone
libcairo
Unknown
Medium
cairo (Ubuntu)
Low
Unassigned
Precise
Low
Unassigned

Bug Description

I use NX to connect to a work computer from home, over the Internet. I recently upgraded to Ubuntu 10.10, and I noticed that GTK programs became very sluggish.

I currently have 1.10.0-1ubuntu3 of libcairo2 installed. If I override this with the Ubuntu 10.04 version of libcairo2, 1.8.10-2ubuntu1, performance is restored. I used LD_LIBRARY_PATH to run GTK programs with the old libcairo2 package.

I'll attach a video demonstrating how much faster gedit is using the old libcairo2 package.

Both my home and work computer run Ubuntu 10.10.

The work computer has these NX packages installed:
nxclient-3.4.0-7
nxnode-3.4.0-14
nxserver-3.4.0-14

The home computer only has the nxclient-3.4.0-7 package installed.

The ping times from my home computer to work computer are about 35ms.

I suspect this issue is related to, or a duplicate of, bug #595845.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libcairo2 1.10.0-1ubuntu3
ProcVersionSignature: Ubuntu 2.6.35-22.35-generic-pae 2.6.35.4
Uname: Linux 2.6.35-22-generic-pae i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Sun Nov 28 03:23:50 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: cairo

Ryan Prichard (ryan-prichard) wrote :
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software

Changed in cairo (Ubuntu):
importance: Undecided → Low

I use NX to connect to a work computer from home, over the Internet. I recently upgraded to Ubuntu 10.10, and I noticed that GTK programs became very sluggish.

I currently have 1.10.0-1ubuntu3 of libcairo2 installed. If I override this with the Ubuntu 10.04 version of libcairo2, 1.8.10-2ubuntu1, performance is restored. I used LD_LIBRARY_PATH to run GTK programs with the old libcairo2 package.

I first reported this issue against Ubuntu 10.10, but since the problem is in Cairo (or NX), an Ubuntu maintainer suggested I report it here. The Ubuntu bug report is at https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/682338. It has a video attached demonstrating how much faster gedit is using the old libcairo2 package.

Both the home and work computer run Ubuntu 10.10.

In addition to the performance drop, I see JPEG artifacts on rendered text and metacity window decorations. I'm used to seeing some artifacts because NX compresses things like icons with JPEG. NX doesn't normally compress text, window decorations, etc. The slow performance and artifacts suggests that NX is transmitting bitmap data when it should be transmitting drawing commands.

The work computer has these NX packages installed:
nxclient-3.4.0-7
nxnode-3.4.0-14
nxserver-3.4.0-14

The home computer only has the nxclient-3.4.0-7 package installed.

The ping times from my home computer to work computer are about 35ms.

I made a Cairo Git checkout and verified that when I built 1.8.10, gedit was fast, but when I built the newest version, gedit was slow. git bisect identified a single commit where the performance problem began:

commit 33be73dfb76c26e3bb0ab59b2f570d00d9c7be62
Author: Chris Wilson <email address hidden>
Date: Fri Sep 11 14:59:58 2009 +0100

    [xlib] Fix big-line.

    Project lines that exceed the 16.16 limits onto the XFixedLine, as we know
    that top/bottom must fit within the confines of the surface and so will be
    less than 16 bits.

    Sadly this is a run-on patch that also does:
    1. Make FillTiled the default for new GCs.
    2. Stores extend mode as opposed to repeat, and thereby cleaning up some
    inconsistent code.
    3. Remove the special casing for unbounded trapezoids, as it is redundant
    with the polygon clipping.
    4. Tidy the logic for deciding when to use the core protocol
    (_categorize_composite_operation)

When I searched the Internet for "Ubuntu 10.10 slow NX", I noticed a similar-looking problem reported on a forum.
 - http://ubuntuforums.org/showthread.php?t=1625513

Ryan Prichard (ryan-prichard) wrote :
Zoide (andresodio) wrote :

Thanks Ryan for finding the guilty library! I have posted instructions for a workaround in the Ubuntu forum thread. I'm sure you already figured that out for yourself, but please let me know if there's anything I missed or can be improved ;)

Zoide (andresodio) wrote :

Here is the link to the workaround I posted: http://ubuntuforums.org/showpost.php?p=10590940&postcount=5

Changed in cairo (Ubuntu):
status: New → Triaged
Changed in libcairo:
importance: Unknown → Medium
status: Unknown → Confirmed

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.

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).

Levi Purvis (lpurvis) wrote :

This issue still persists in Ubuntu 11.10. Please consider adding the patch suggested at the end of comment 3 on the freedesktop.org bug report to the Ubuntu patch set, as it simply comments out a check for a "buggy_repeat" flag against X.org 6.9. Since Ubuntu distributes a newer X.org, the buggy_repeat check is unnecessary. I verified the patch against the cairo 1.10.2-6ubuntu3 source package (had to adjust the line offsets) -- it resolves the issue with NX.

https://bugs.freedesktop.org/show_bug.cgi?id=32014#c3

Levi Purvis (lpurvis) wrote :

Attaching above referenced patch adjusted for Ubuntu 11.10.

The attachment "nx_cairo_1.10.2-6ubuntu3.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Evan Broder (broder) wrote :

Unfortunately it's a little more complicated than just which X server Ubuntu 12.04 contains. If you were to, say, X-forward an application from an Ubuntu 12.04 machine to a machine with an old server, you could crash that X server. Ideally, we would patch cairo to specifically detect the NX agent's X server, but I haven't been able to come up with a way to do that.

After consulting with Sebastien, I've come up with the attached patch, which still disables the workaround for buggy repeat, but only for the specific X version that that the NX agent advertises. While our best judgement is that the NX agent is likely to be significantly more common than X-forwarding to an X server from 7 years ago, I'd still like to limit the scope of the change.

I've uploaded a test build with this patch to my PPA (http://launchpad.net/~broder/+archive/ubuntu-tests); it should build and be available shortly. I'll attempt to test it, but if people who actively use NX could test it as well, that would be appreciated. Assuming no snags, I'll plan to upload it to the archive in the next few days.

(In the mean time, I'm going to go ahead and unsubscribe ubuntu-sponsors, but I'll keep an eye on the bug myself)

Daniel Kulesz (kuleszdl) wrote :

Looks like the NX folks have released an update which promises to fix this issue:

http://www.nomachine.com/news-read.php?idnews=371

Did someone try it already?

Maxime D. (maxime-d) wrote :

It seems to be OK for me, I'm running this new release with native cairo packages :)

Maxime D. (maxime-d) wrote :

On Ubuntu 12.10 which has libcairo2 1.12, the bug come back ! :(

It's OK when downgrading the package to the 1.10 version of Ubuntu Precise...

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.

Changed in libcairo:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.