20242 - Scrolling very slow on my 2nd monitor

Status: VERIFIED INVALID

(Core :: Web Painting, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

On my 2nd monitor, the resolution is 1024x768 and lacks hardware accelerator, so
slow scrolling is noticeable.

Scrolling mozilla.org with the scrollbar is _painful_ to say the least. An order
of magnitude slower than 4.5 on the same monitor, same sized window.

Comment 1

[Patrick C. Beard]

Bit depths? Is your second monitor at a different bit depth from your primary?
This is really a widget bug, since it does scrolling on behalf of the view
system.

Comment 2

[Simon Fraser [no longer active]]

This isn't bit depth, it's because pink doesn't have the drivers installed for
his second screen, so QuickDraw is running unaccelerated.

Comment 3

[Mike Pinkerton (not reading bugmail)]

well, yes, but it still shouldn't be _that_ slow, should it? I think i may have
made it better with my scroll-by-page fix for gfx scrollbars, but the point is it
is still not as smooth as navigator, on the same monitor, same window size.

Comment 4

[moshev]

I am not sure if it's the same bug, but there are certain ULS
that scroll Extremely slow on my system, (it is Linux). For
example trying to scroll when in http://www.linux-mandrake.com/lothar/
is painfully slow.
Should i open a separate bug for this, or are those two related?

Comment 5

[moshev]

even better example is http://www.linux-mandrake.com/lothar/news.html
On this page, scrolling with scrollbar or with up/down arrows takes
as much as .5-.8 seconds per redraw, on pII - 300 Mhz, 256mb ram, on Linux.
(build 2000030809)

Comment 6

[olaf]

That page has a background image which is 4x2000 (!) pixels in size. They use it
to get a vertical stripes background. Of course this is unnecessary and a 4x1
image would suffice. I replaced the image with a minimum version and it scrolls
much faster. (Tested under Linux, build 2000030913)

Result: scrolling is slow with big background images. This makes it very likely
the reason is bug 18992.

Comment 7

[Patrick C. Beard]

Reassigning all view bugs to kevin.

Comment 8

[Kevin McCluskey (gone)]

Don, this sounds like another bug which may be addressed by your modifications 
for pattern blitting.

Comment 9

[dcone (gone)]

Tiling slowness will be addressed by 31044.

*** This bug has been marked as a duplicate of 31044 ***

Comment 10

[Simon Fraser [no longer active]]

We have no evidence that this slowness is due to tiling.

Comment 11

[Simon Fraser [no longer active]]

This bug morphed into a bug about slow rendering with tiling. It should not have. 
The original report was a general problem with slow scrolling on any page.

Comment 12

[dcone (gone)]

Can you retest this.. there were some big performance changes since the bug was 
created, especially on the Mac.  I don't have a second monitor to test this.. 
right now.. just want to make sure it is an issue still. 
Also are you saying that scrolling is slow in general (really slow with 
unaccelerated Mac), or something about the way we handle the second monitor 
makes us very slow.  And did you say your bit depths are the same or different. 
If they are different it may be a dithering issue since we use a single depth 
offscreen.. and if the second monitor is a smaller bit depth there may be some 
dithering..

Comment 13

[Mike Pinkerton (not reading bugmail)]

i just tested tinderbox with mozilla vs. 4.7 (same sized window on the same 2nd 
monitor, this time accelerated -- i got a new machine) and with native 
scrollbars, the scrolling is very comparable.

don't even ask about gfx scrollbars. ;)

should i mark this as invalid, since we already have other bugs to do with gfx 
scrollbar issues?

Comment 14

[Mike Pinkerton (not reading bugmail)]

just tried with acceleration turned off and we're just as pathetic as 4.x. I 
can't really tell a difference (again with native scrolling). sfraser and I agree 
we can mark this one invalid.

Comment 15

[Chris Petersen]

Marking verified invalid per last comments.