255703 - Scrolling performance with transparent background has regressed since 1.8a1

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Stephen Moehle]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040815
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040815

Scrolling performance on pages with background images regressed sometime between
1.8a1 and 1.8a2.  In this particular case, the background image is fairly large
- 800 x 768 with about 2/3 of it being transparent.  In 1.8a2 and the latest
trunk builds, scrolling is very jerky with the scrollbar thumb not keeping up
with the mouse at all.  It also looks like some mouse events are being lost
since, when scrolling stops, the thumb never catches up to the current mouse
position.  If the mouse is moved even only 1 pixel, the thumb will jump to the
correct position.  If the thumb is dragged slowly enough, scrolling is nice and
smooth.  So to replicate, scroll faster.

In 1.8a1, scrolling is much smoother, even when dragging the thumb very fast. 
The thumb does lag the mouse somewhat but nothing as bad as it is now.

If the background image is removed, scrolling is performance is OK.

I see this problem on Windows XP as well as Linux, but the effect is much more
pronounced on Linux.

Reproducible: Always
Steps to Reproduce:
1. Load the attached test case.
2. Scroll up and down at different speeds by dragging the thumb with the mouse.
3. Notice that the faster the thumb is dragged, the worse scrolling performance
seems to get.

Comment 1

[Stephen Moehle]

Attachment: Background image for test case

Comment 2

[Stephen Moehle]

Attachment: Testcase using previously attached image

Comment 3

[Stephen Moehle]

Well, I finally found archive.mozilla.org. This regressed between 2004-06-01-05
and 2004-06-02-06 Linux trunk.  In that window, I found bug 241939, and if I
backout the changes made to mozilla/gfx/src/gtk/nsImageGTK.cpp for revision
1.136, the problem goes away and scrolling becomes smooth and responsive.

Changing component and CC'ing the guilty party.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

None of the patches in bug 241939 change nsImageGTK.

Comment 5

[Stephen Moehle]

Oops. Wrong bug, sorry. It is really bug 244506. CC'ing real guilty party.

Comment 6

[tor]

What graphics card and version of X server are you running?

Comment 7

[Stephen Moehle]

I am running Fedora Core 2, fully patched, so that is X.org 6.7.0 and the video
card is an ATI Radeon Mobility something-or-other.  I am using the stock X.org
radeon driver, not the ATI ones.

Comment 8

[Andrew Schultz]

I'm seeing the same thing with a similar setup (FC2, ATI card with X Radeon driver)

marking NEW

Comment 9

[Markus Hübner]

As this is also visible on win32 should we change OS to ALL?

Comment 10

[Andrew Schultz]

not unless win32 uses nsImageGtk.cpp.

Comment 11

[tor]

While the old tiling method code was added back in for use with buggy
servers (bug 256328), this seems to be a problem that the raster
operations being used by the new method are unaccelerated or slow
with your particular card/driver combination.  Without adding a
benchmark framework to gfx (which we don't really want to do) we
can't test to see if the old method should be used.

Since a fix isn't on the table and the new method should be faster
for most people, marking 1.8a6-.

Comment 12

[Andrew Schultz]

*** Bug 317446 has been marked as a duplicate of this bug. ***

Comment 13

[Mats Palmgren (inactive)]

WFM, Firefox trunk on Linux.

Does anyone else still see this bug in a recent trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 14

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070606 Minefield/3.0a6pre

Works for me, too. If anyone can reproduce in a trunk build, please reopen.

->WORKSFOMRE

Comment 15

[Andrew Schultz]

With linux build 2007-06-18-09-trunk, it still takes ~1 second to paint each page (after hitting pgdn) with the attached testcase.

Comment 16

[Wayne Mery (:wsmwk)]

Andrew (or anyone), still see this with newer trunk?

Comment 17

[Zack Weinberg (:zwol)]

WFM with 8.0 (probably not the same graphics card, though).  I see this has been reopened before, so I'm also gonna recategorize it under Core:Graphics in case it needs to be reopened again.