Closed
Bug 380473
Opened 18 years ago
Closed 17 years ago
repainting (scrolling) tinderbox takes about a second
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: dbaron, Assigned: vlad)
References
()
Details
(Keywords: perf, regression)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
vlad
:
review+
|
Details | Diff | Splinter Review |
Painting http://tinderbox.mozilla.org/Firefox/ has gotten much slower since bug 368247 (border painting rewrite) landed. Doing PgUp/PgDown on tinderbox used to be instantaneous; since that patch landed it has taken about a second.
Steps to reproduce:
1. load http://tinderbox.mozilla.org/Firefox/
2. hit the PgDn key a few times to scroll down by pages
Expected results: scrolling down occurs instantaneously
Actual results: the very top slice of the page (the overlap, which is blitted instead of repainted) appears instantaneously, but the rest of the page takes about a second to appear. top shows that the X server is using 97%-98% CPU.
Works correctly in Linux Firefox nightly 2007-04-30-04-trunk.
Broken in Linux Firefox nightly 2007-05-01-04-trunk.
Therefore, I'm presuming it's due to bug 368247.
I'm using an IBM T42 laptop with an ATI Mobility Radeon 9600 M10 video card; I use the ATI proprietary drivers (xorg-x11-drv-fglrx-8.36.5-1.lvn6 from Livna) on Fedora Core 6, but without the kernel module (kmod-fglrx).
I'd have filed this earlier if I hadn't been blaming the slowness on cycle collection pauses.
Flags: blocking1.9?
Reporter | ||
Comment 1•18 years ago
|
||
I see pretty much the same thing on my old laptop: a Dell laptop with an ATI FireGL 9000, running Fedora development (almost Fedora 7 now), with the radeon driver (the free one). Though on the older machine the repaint pause is more than a second. So it's not driver-specific.
I've also seen the repaint pauses on articles on the New York Times, and at the bottom of the page on bugzilla.
Reporter | ||
Comment 2•18 years ago
|
||
Setting doSeparateSides to false makes the performance problems go away (although not all of the borders are drawn). Not doing the PushGroup, SetOperator, and PopGroupToSource also makes the performance problems go away, although the drawing problems are even worse that way.
Reporter | ||
Comment 3•18 years ago
|
||
This bug is bad enough that it's making it hard for me to dogfood the trunk -- I don't think it's acceptable to ship an alpha with it.
Reporter | ||
Comment 4•18 years ago
|
||
This turns off antialiasing of borders, which I think we should do until we can get the performance back some other way.
Attachment #265592 -
Flags: review?(vladimir)
Assignee | ||
Comment 5•18 years ago
|
||
Can we do this on linux only? It doesn't seem to be as much of an issue on win32 and mac, no?
Flags: blocking1.9? → blocking1.9+
Reporter | ||
Comment 6•18 years ago
|
||
I'm a little scared of doing this in a platform-specific way since I worry it'll end up permanent rather than temporary and we'll end up shipping without feature parity. But here it is.
If this lands, I'll file a bug on undoing and nominate it for blocking1.9.
Attachment #265592 -
Attachment is obsolete: true
Attachment #265691 -
Flags: review?(vladimir)
Attachment #265592 -
Flags: review?(vladimir)
Assignee | ||
Comment 7•18 years ago
|
||
Comment on attachment 265691 [details] [diff] [review]
patch to disable antialising of borders
Yeah, I agree -- FWIW, I'm looking at this right now on linux to see if I can figure out what the performance issues are.
Attachment #265691 -
Flags: review?(vladimir) → review+
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → vladimir
Reporter | ||
Comment 8•18 years ago
|
||
Well, I checked the above patch into the trunk and filed bug 381735 on reenabling the antialiased border drawing, but it looks like you want to keep using this bug (since you just assigned it to yourself), so not marking fixed.
Assignee | ||
Comment 9•18 years ago
|
||
This -should- be fixed by checked-in patch from bug 368247; dbaron, can you check and resolve this if so?
Comment 10•17 years ago
|
||
This seems to be WFM/FIXED now. Any reason to keep this still in 1.9+ list?
Reporter | ||
Comment 11•17 years ago
|
||
Marking fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•