242364 - Serious performance issues painting a fixed-pos scaled image with opacity

Status: NEW

(Core :: Web Painting, defect)

Description

[Boris Zbarsky [:bzbarsky]]

This is about the worst-case scenario you can think of... the image is a 640x480
jpeg, scaled, fixed-pos, and has opacity.  Though removing the opacity really
doesn't help much....  In any case, any scroll operation (which has to repaint
the image) takes about 3-4 seconds on my computer.  A profile shows that of
213851 hits (for about 20 seconds worth of scrolling) we have:

  188939 under gdk_image_get (mostly under XGetImage(), which mostly calls
         _XReadPad(), which mostly sits about in select()).  This is all called
         from nsDrawingSurfaceGTK::Lock.
   10613 under nsBlender::Do24Blend

Other that this blending stuff, the rest of the time (what little there is) is
spent under nsRenderingContextGTK::DrawScaledImage() (which is not unreasonable).

So why is getting that image off the (local!) X server taking so much friggin' time?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Image

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Note, the original page I saw this on was http://hull.ath.cx/formbug.html --
perf was even worse there, probably due to the form controls....

Comment 3

[tor]

Performance for this seems to vary quite a bit.  On a 1.13GHz P3 with a
SuperSavage IX/C this testcase is a little laggy, but perfectly useable.
On the other hand, a 2.4GHz P4 with an Intel 845G (integrated) graphics
chip it's painfully slow - about a second per scroll operation.  Same
version of fedora on each machine.

What graphics setup do you have on your machine ("lspci | grep VGA")?

Comment 4

[Boris Zbarsky [:bzbarsky]]

01:00.0 VGA compatible controller: nVidia Corporation RIVA TNT2 Model 64 (rev 15)

Yes, I know it's not that new... ;)  And this is a P3-733.

Comment 5

[Aaron Kaluszka]

Isn't this just a combination of several poor performance bugs: fixed position,
scaling, and opacity, which already have open bugs?

See:
bug 201307 and bug 90198 (fixed position)
bug 194627 (NVidia)
bug 193849 and bug 179155 (opacity)

I couldn't find any open bugs on scaling, but I seem to remember a bug(s) about
that because of the Mozilla eyeball animation testcase... the animated part made
it even worse.

Anyway, it scrolls okay, but slower than normal (about as slow as anything with
fixed position), with my system:
dual Athlon XP 1700+, 1024MB RAM, ATI Radeon 9700 128MB, Windows 2003 ES, 1600x1200

Comment 6

[Boris Zbarsky [:bzbarsky]]

aaron, the key difference is that this bug, unlike those, points to the exact
place in the code that has a performance problem on this page.  The vague bugs
are fine and dandy for feel-good purposes, but to actually make this better we
need to analyze particular examples and see exactly what makes them slow.  Feel
free to make those bugs dependent on this one, of course.

Comment 7

[Aaron Kaluszka]

Just for reference, found the scaling bug: bug 163975

Comment 8

[Bryan]

This appears to be resolved (at least for me) in current trunk builds.  It's smooth as butter and quite fast now:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090210 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090210050102

~B

Comment 9

[Ryan Jones-Ward [:sciguyryan]]

BZ - can you still reproduce this? If not then it was probably fixed by bug 564991 and can be closed.

Comment 10

[Ildar Nurislamov]

For me problem still exists on http://wii.ign.com/ on WinXP. Transparent transitions with large image are very slow when site is zoomed.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ryan, I no longer possess either the hardware or OS this bug was originally filed on.  So me testing would be completely useless.

Comment 13

[Nathanael Noblet]

So I had previously filed a bug without knowing the exact cause, however on all builds of Firefox for linux, we'd have major system slowdowns (Quad Core, 4G RAM, ATI 4670). We've isolated the problem to changing opacity on a dynamically scaled images. Our test site is http://www.shopthevillage.ca/ if we remove the scaling the transitions are smooth and performance is as expected. Otherwise during a transition the system is unresponsive for a *long* time. I've tried FF 4B1 with the same effect. I'm closing my duplicate bug report. However am very much interested in helping get this fixed. Let me know what to do.

Comment 14

[José Jeria]

(In reply to comment #10)
> For me problem still exists on http://wii.ign.com/ on WinXP. Transparent
> transitions with large image are very slow when site is zoomed.

What Firefox version did you test this with? Trunk build?

Comment 15

[José Jeria]

(In reply to comment #13)
>  I've tried FF 4B1 with the same effect. 

Do you still see this issue with a trunk build:
ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

Comment 16

[Nathanael Noblet]

Yup. Downloaded moments ago same issue.

Comment 17

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to comment #13)
> So I had previously filed a bug without knowing the exact cause, however on all
> builds of Firefox for linux, we'd have major system slowdowns (Quad Core, 4G
> RAM, ATI 4670). We've isolated the problem to changing opacity on a dynamically
> scaled images. Our test site is http://www.shopthevillage.ca/ if we remove the
> scaling the transitions are smooth and performance is as expected. Otherwise
> during a transition the system is unresponsive for a *long* time.

Scaling is done by the X11 graphics drivers so is driver dependent.

Are you using the radeon driver from xf86-video-ati with kms?
This sounds like
https://bugs.freedesktop.org/show_bug.cgi?id=27139

We can work around that by using EXTEND_PAD instead of EXTEND_NONE.  (i.e. undo our workarounds for bad extend pad.)
Bug 422179 will switch back to extend pad with upscaling.
I think we should also use extend pad for downscaling as GL-supporting video cards are more likely to support extend pad than extend none.

See also bug 581797 comment 9 and subsequent.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Note that this bug was originally filed against our client-side image scaling code, and on a machine using an nVidia card (and non-accelerated drivers, which didn't matter much since the scaling was client-side).  In other words, sounds like bug 580491 isn't a duplicate of this bug.

Comment 19

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to comment #18)
> Note that this bug was originally filed against our client-side image scaling
> code, and on a machine using an nVidia card (and non-accelerated drivers, which
> didn't matter much since the scaling was client-side).

Should me mark this bug fixed by the cairo switch, then?

> In other words, sounds like bug 580491 isn't a duplicate of this bug.

OK.  Let's reopen and discuss that there.