Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 386440 - Cairo image scaling/composite significantly slower on Linux.
: Cairo image scaling/composite significantly slower on Linux.
: mobile, perf
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: unspecified
: x86 Linux
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Milan Sreckovic [:milan] (PTO through Oct 23)
Depends on:
Blocks: 334720
  Show dependency treegraph
Reported: 2007-06-30 10:17 PDT by Oleg Romashin (:romaxa)
Modified: 2011-10-07 16:26 PDT (History)
23 users (show)
mtschrep: blocking1.9-
mtschrep: wanted1.9+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Simple scaling in Optimize function (11.32 KB, patch)
2007-07-20 01:43 PDT, Oleg Romashin (:romaxa)
no flags Details | Diff | Splinter Review
Profile data for browser_paper.html (165.15 KB, application/zip)
2007-11-10 19:43 PST, Oleg Romashin (:romaxa)
no flags Details
Enable 16bpp (or native visual xrender fmt) (1.10 KB, patch)
2008-07-22 16:08 PDT, Oleg Romashin (:romaxa)
no flags Details | Diff | Splinter Review
No conflict with force24 bit option (1.86 KB, patch)
2008-11-15 08:41 PST, Oleg Romashin (:romaxa)
no flags Details | Diff | Splinter Review
Enable using system visual format by preference (2.69 KB, patch)
2008-12-02 13:22 PST, Oleg Romashin (:romaxa)
no flags Details | Diff | Splinter Review

Description Oleg Romashin (:romaxa) 2007-06-30 10:17:26 PDT
Cairo image scaling/composite significantly slower on Linux.
For example if page contain a lot of scaled images, or Mozilla started on X with Big DPY (possible to check with layout.css.dpi option)

On the same laptop (T43 1.8GHz, RAM 1024Mb, ATI x300)
Open URL and try scroll many times (30-40) and fast with mouse wheel button...

Linux Debian SID fglrx: possible to make some coffee while it finish scrolling
Windows XP            : Scrolling works very fast without any delays...
Comment 1 Oleg Romashin (:romaxa) 2007-06-30 10:20:01 PDT
On the same PC under Linux Opera works with the same speed as SM2.0 or FF3 on windows (may be some faster..).
Comment 2 Dennis Jacobfeuerborn 2007-07-01 15:20:11 PDT
Could this be a driver problem? I'm using the proprietary NVidia driver and the URL works fine for me.
Comment 3 timeless 2007-07-02 04:35:43 PDT from our perspective, it's a cairo problem. the video system we're using doesn't have a fancy driver at all. which means cairo falls back to something else. the fallback is terrible.

the t43 should have a reasonable graphics driver.

now, it could be a bug in how we use cairo, or it could be a bug in the cairo implementation. but it is not acceptable to blame the video driver. this stuff works fine on the same hardware.
fglrx (possibly an acronym for FireGL and Radeon Linux driver) is the name of the Linux display driver used for ATI Radeon and ATI FireGL family video adapters. It contains open source and closed source parts. For proper Direct Rendering Infrastructure (DRI) support, the kernel source code for the currently running kernel must be installed and compiled. The driver can work without the kernel module, but DRI will not be available.

romaxa: are you using the kernel module?
Comment 4 Vladimir Vukicevic [:vlad] [:vladv] 2007-07-02 08:10:55 PDT
(In reply to comment #2)
> Could this be a driver problem? I'm using the proprietary NVidia driver and the
> URL works fine for me.

Yeah, almost certainly a driver problem.  The ATI proprietary drivers have never been all that high quality, and we're going down a different path in the X server now than previous versions of fx, or from what opera, etc. is using.  So ATI's driver is probably hitting some case where everything needs to be copied back into system memory, maybe even back into application memory and then back to the card to be displayed.

Not pretty, but I doubt we'll do anything about it, sorry -- ATI keeps promising they'll fix their linux drivers, but they've been saying the same thing for the past 5 years.  You might want to try the open-source ATI driver and see if that helps.
Comment 5 Oleg Romashin (:romaxa) 2007-07-02 09:19:42 PDT
I'm trying to understand how Opera doing that  Composition/Scaling/.... without any hardware drivers, without big count of memory...

There are probably very secret and perfect algorithms... 
Comment 6 Vladimir Vukicevic [:vlad] [:vladv] 2007-07-03 09:29:50 PDT
(In reply to comment #5)
> I'm trying to understand how Opera doing that  Composition/Scaling/.... without
> any hardware drivers, without big count of memory...
> There are probably very secret and perfect algorithms... 

Well, it's probably that we're buying into the Linux Dream and they're being pragmatic and doing everything in software...
Comment 7 Oleg Romashin (:romaxa) 2007-07-17 07:52:30 PDT
Tested with OQO Model 2, 384
 WinXP, Mozilla Firefox Trunk.

layout.css.dpi = 200 ()
Open URL or

Try to scroll with finger UP/Down ~10 times.... ;), after ~1-2 minutes it will finished... :(

Comment 8 Oleg Romashin (:romaxa) 2007-07-20 00:12:07 PDT
What do you think about pre-scaling of image surface in ::Optimize function?

If Image have style,attr+or/and DPI!=96, then we can create optimized surface with scaled image... 

It will disable Scale/Composite operations on each repaint...
Comment 9 Oleg Romashin (:romaxa) 2007-07-20 01:43:51 PDT
Created attachment 273099 [details] [diff] [review]
Simple scaling in Optimize function

With this patch Image scaling happens only once...
Comment 10 Stuart Parmenter 2007-07-20 14:16:20 PDT
and when the image is used multiple times on a page...?
Comment 11 Oleg Romashin (:romaxa) 2007-07-21 05:07:03 PDT
Ups... I did not think about it :(
Comment 12 Oleg Romashin (:romaxa) 2007-09-03 14:15:44 PDT
Click on "Mozilla Engine" button
Start timer.
Click on "Documentation" button
Stop Timer.

FF3 trunk
Linux,ATI,No HW acceleration:  ~  10 sec
Linux,ATI,fglrx HW acceleration:  ~  3 sec
Windows,Nvidia, Nvidia Driver:  ~  1 sec

Linux,ATI,No HW acceleration:  ~  2 sec
Comment 13 Vladimir Vukicevic [:vlad] [:vladv] 2007-11-09 16:12:22 PST
Minusing this for now; it's largely a driver issue, and there a bunch of other bugs that cover basically the same case.  The one thing we're thinking of doing is creating a pref, and possibly doing some timings on startup, and doing pure software rendering (that is, in cairo, using only in-memory image surfaces and never using the x server for anything other than the final display).
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2007-11-09 16:41:57 PST
Would that really be faster?  As I recall, doing it all client side is slower than using Render, which is slower than using Xlib....
Comment 15 Oleg Romashin (:romaxa) 2007-11-10 19:38:30 PST
It would really faster if Render not accelerated... (GFX-GTK2 backend working much faster)

But for testcase
Render and HW acceleration will not help, because cairo does not have implementation of cairo_xlib_surface_fill and it always works with _cairo_surface_fallback_fill

Comment 16 Oleg Romashin (:romaxa) 2007-11-10 19:43:06 PST
Created attachment 288178 [details]
Profile data for browser_paper.html

Profile data for testcase
and _cairo_surface_fallback_fill.
Comment 17 Vladimir Vukicevic [:vlad] [:vladv] 2007-11-22 15:41:41 PST
I haven't looked at the profile data, but it doesn't matter -- fallback_fill is correct in this case, because that's where tessellation happens.  After that composite or composite_trapezoids is used, which goes to the surface backend.  It's only if the surface doesn't implement composite or composite_traps that pixman gets involved.
Comment 18 timeless 2007-12-05 11:24:12 PST
I'm told that mobile is supposed to be treated as tier 1. as such, i think vlad's minus is no longer valid.
Comment 19 Mike Schroepfer 2007-12-06 11:42:50 PST
Taking off the blocking 1.9 list again.  Timeless Mobile is Tier 1 post Gecko 1.9 - we still would really want to get this fixed but it will not block the 1.9 release.
Comment 20 Oleg Romashin (:romaxa) 2008-07-22 16:08:41 PDT
Created attachment 330850 [details] [diff] [review]
Enable 16bpp (or native visual xrender fmt)

With this patch we are getting significant performance improvement on N8XX / 16bpp visual format.
Without this patch scroll time on from "Microb Engine" -> "Documentation" takes ~ 11 sec.
With this patch it takes ~ 2 sec

Also panning and scrolling much more faster now...

Also Fennec browser looks much more faster with this fix.
Comment 21 Oleg Romashin (:romaxa) 2008-11-15 08:41:26 PST
Created attachment 348343 [details] [diff] [review]
No conflict with force24 bit option

Disable 16 bit usage if force 24 bit option enabled
Comment 22 Oleg Romashin (:romaxa) 2008-12-02 13:22:59 PST
Created attachment 351034 [details] [diff] [review]
Enable using system visual format by preference

As I understand it is not very good idea to use always system format (and it can affect on some 16 bit desktop systems...).
Here is the preference to use it when it is required.
Comment 23 Oleg Romashin (:romaxa) 2009-02-23 04:31:43 PST
Any updates for this patch review?
Comment 24 Frederic Plourde (:fred23) 2009-03-23 07:56:55 PDT
I've been investigating important fennec pageload slowdowns associated with chinese fonts and the problem turns out to be closely related to this bug. I've applied the patches and notices significant speed-ups, so if we could just refocus our interest on this bug (and on bug 459078), that'd be great !
Comment 25 Oleg Romashin (:romaxa) 2010-03-23 22:16:25 PDT
Probably we should take latest pixman with improved scaling functionality, also merge with bug 545632.
Comment 26 Jeff Muizelaar [:jrmuizel] 2010-03-24 11:22:43 PDT
I don't really like adding new prefs. What's the reason we can't just do the right thing?
Comment 27 Mike Shaver (:shaver -- probably not reading bugmail closely) 2010-11-02 23:28:38 PDT
Is this still a latent win for Fennec, or did the work in bug 545632 capture the valuable part?
Comment 28 Chris Lord [:cwiiis] 2011-10-07 16:26:17 PDT
Yes, it looks like the patch in bug #545632 makes this the default behaviour now. Marking this as fixed, please re-open if this is an error.

Note You need to log in before you can comment on or make changes to this bug.