Bug 26869

Summary:	cairo 1.8.10 slows down firefox on sparc
Product:	cairo	Reporter:	Uwe <gfufo>
Component:	xlib backend	Assignee:	Carl Worth <cworth>
Status:	RESOLVED MOVED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium	CC:	jmccarty
Version:	1.8.10
Hardware:	SPARC
OS:	Solaris
Whiteboard:
i915 platform:		i915 features:

Description Uwe 2010-03-03 11:42:11 UTC

I do compile all stuff on Solaris 10 (Sparc) myself.
After compiling and installing cairo 1.8.10, firefox 3.0.18 feels
extremely sluggish. The Xsun process (Solaris' X11 server) consumes
lots of CPU cycles. I recompiled 1.8.8 and reverted to this version,
then firefox runs normal again.
Something's wrong with pixmap handling?

Both version have been compiled using the same options:
CC=cc CFLAGS="-O" ./configure --prefix=/export --enable-static=no

Comment 1 M Joonas Pihlaja 2010-03-03 11:57:51 UTC

There's not a lot of difference between 1.8.8 and 1.8.10, and the most probable culprit for the slowdown looks to me like it might be:

  [xlib] DO_XCOPYAREA and DO_XTILE optimizations break with Window source

  http://cgit.freedesktop.org/cairo/commit/?h=1.8&id=c4cc2247813f26db79fc2c6aa789856569497613

If you could try reverting that patch and recompiling to see if it's causing your slowdowns that would be great.

Comment 2 Uwe 2010-03-03 14:26:57 UTC

I took the 1.8.10 sources, omitted both "src->owns_pixmap &&"
from cairo-xlib-surface.c, recompiled and tested again - firefox
runs fine with that.
So not only Windows but Solaris as well is affected, at least
on Sparc (afaik Solaris x86 uses the Xorg server that might
behave differently).

Comment 3 Jason McCarty 2010-05-04 16:14:52 UTC

I'm also affected by this bug, on linux 2.6.28, with a 1.3 GHz athlon. Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580175 . I can confirm that removing the first src->owns_pixmap change restores my performance. The second src_owns_pixmap test makes no difference for me.

Comment 4 Chris Wilson 2010-06-13 02:00:34 UTC

This is unfortunate but that patch is a correctness fix as we cannot determine when using XCopyArea is actually going to leave blank areas where the source is clipped by children. This is an incorrect result.

A patch to perform the intermediate blit instead of falling back would be appreciated. The alternatives are to do as Mozilla do and patch this out and ignore the consequences, somehow determine whether an external drawable is a pixmap or window on construction [this would be useful in any case], or fix your Xserver to support XRENDER. The last option will the biggest performance improvement.

Comment 5 GitLab Migration User 2018-08-25 13:55:58 UTC

-- 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/273.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.