371892 - Cairo image scaling significantly slower with some Render versions

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Current trunk build

STEPS TO REPRODUCE:
1)  Make sure scaling of large images is turned on
2)  Make sure your window is smaller than 800x800px
3)  Load https://bugzilla.mozilla.org/attachment.cgi?id=256584
4)  Try to move the window around, move other windows on top of it, etc

EXPECTED RESULTS: Image loads scaled, browser doesn't hang, moving other windows around works.

ACTUAL RESULTS:  Image loads scaled, but the browser hangs for 4-5 seconds on every paint operation while X takes up 100% CPU.  Moving other windows on top of the browser window (which causes expose events, of course), has the same effect -- 4-5 seconds hang per mouse move).

I tried hacking nsThebesImage to set a CAIRO_FILTER_FAST filter on its patterns, and while this did help somewhat I was still getting hangs on the order of a second.

The pre-cairo code (where if I recall we do client-side scaling for things with an alpha channel and XlibRectStretch whenever we can get away with it) produces output somewhat equivalent to that I get with CAIRO_FILTER_FAST but does it _much_ faster.

This likely depends on the Render version.  I have Render "version 0.9 opcode: 155, base error: 181" according to xdpyinfo, and X.Org version 6.8.2 (basically, the stock X on FC4).  But dbaron says that trunk is slower than Firefox 2 at scaling images for him on FC6 as well...

This is basically dogfood for me; it makes dealing with screenshot attachments and reftests almost impossible, and makes other day-to-day browsing a minefield.

Comment 1

[Oleg Romashin (:romaxa)]

Attachment: Page with may ARGB pictures.. which requires a lot of XrenderComposite

Comment 2

[Oleg Romashin (:romaxa)]

I have found some another testcase...

Current Trunk Build, Cairo-xlib,
Prepare vnc server with big DPI, or change dpi from about:config...
Xvnc -geometry 1280x1024 -dpi 400 -ac -depth 16 :6

DISPLAY=:6 ./run-mozilla.sh ./firefox-bin 'jar:https://bugzilla.mozilla.org/attachment.cgi?id=257831!/index.xhtml'

Try to scroll it up and down....

Scrolling extremely slow...


 

Comment 3

[Oleg Romashin (:romaxa)]

I think it happens because:

1) Gecko create normal not scaled cairo surface
2) After changing DPI Gecko not transform cairo_image_surface,
  and cairo need to do scaling by self for each paint... XrenderComposite work extremely frequently. 
3) Also if Destination Server has depth 16/8 color... then XrenderComposite works still much slower....

I have found a lot of stuff in old  src/gtk2/nsImageGTK.cpp, related to image composite, color conversations... May we should also optimize thebes backend in this way?

Comment 4

[Oleg Romashin (:romaxa)]

Ok, Source Image has original size 150x112.
If Image has width,height parameters, then Gecko do scaling of Images on each paint -> it call additional expensive Composition for image Surface...

nsThebesImage::Draw src [0 0 150 112] dest [8 8 300 400] tx [0.000000 0.000000] dec [0 0 150 112], doSnap: TRUE

I think after changing destination image size, we should also change source size, to prevent permanent scaling on each paint....

Comment 5

[Boris Zbarsky [:bzbarsky]]

It's very common to have the same source image painting at different scales (spacer gifs!).

In any case, this bug is not about the fact that we scale on every paint -- we've always done that.  This bug is about the fact that the scaling algorithm we use is slow enough that it's affecting dogfood use of our browser.  Please file separate bugs on any other issues you have.

Comment 6

[:aceman]

Even displaying an image of 1280x960 scaled to 1000x850 takes 10secs on my P3 1400Mhz. On FF2 it takes a split of a second. The same image unscaled renders fine on FF3. Moving and scrolling is slow as the reporter said. I am using the opensource nv X11 driver. The speed is going down even between the betas (3 -> 4)

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Can you still reproduce this problem?

Comment 8

[:aceman]

No I can't, on testcase in comment 0 and comment 1. They paint and scroll reasonably fast (FF7). However, I have changed my setup since then (to Phenom X4 2000Mhz, ATI radeon HD 4350 with OSS drivers, X.org 1.9.5).