Closed Bug 268218 Opened 16 years ago Closed 16 years ago
Scrolling on all pages is slow and jerky: builds 20041105 and after
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041104 Camino/0.8+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041104 Camino/0.8+ If you compare scrolling on any page between the 20041104 build and the 20041105 build, there is a remarkable difference. The build on the 4th is relatively quick and smooth at scrolling, whereas the build from the 5th is jerky and slow. My tentative guess is that it's due to this update: update nib files to 10.2+ format, done to make future modifications easier, get rid of future incompatability issues, memory usage improvements (objects are keyed), possible performance improvements, no bug which AFAIK happened after the 20041104 build was uploaded. Reproducible: Always Steps to Reproduce:
It reproduces. 2004110618 (v0.8+)
Confirmed. 2004-11-06 NB on Mac OS X 10.3.6.
I'm opening up this bug with reservations. I have tested on a slow machine and noticed a decrees in speed but with my fast home machine I couldn't notice any difference. Tough I must say these bugzilla page redraw like crap and choppy. This is using 2004110708 (v0.8+) on 10.3.5.
Severity: normal → blocker
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
I notice a distinct difference between the Nov 04 and Nov 07 builds. When I use the 07 build for a bit, it becomes tolerable, but when I switch back to the 04 build the speed increase is dramatic. I ran Quartz Debug while scrolling in both builds, and it looks like in 04 build we are only updating the part that scrolls into view (as I believe we should), but in the 07 build we are updating the entire viewable area.
I think the Bugzilla and phpBB fora seem to be the worst examples of this jerky/slow scrolling; on other pages it becomes fairly unnoticeable after running for a few minutes (1.33 GHz PBG4). I've also noticed some really slow typing in text boxes like this one in Bugzilla--once the text gets to the poing that the text box has a scroll bar. The cursor seems to be flashing a lot more rapidly, as if it's updating very frequently. I know there's another bug about this in Bugzilla, but I'd never noticed it until getting a post-20041104 0.8+ build, so it's certainly gotten worse....
josh? any ideas here? they're fingering your nib changes. what else changed on the mozilla trunk in that time period? any gecko changes?
When looking at all mozilla trunk checking on november 3,4,5 I think that Bug 267302 is most likely the cause of our scroll issues. Anybody care to back out and test?
I don't have any ideas based on the patches I've watched in the past couple of weeks. I highly doubt it is my nib changes - literally all I did was open, switch format to 10.2+, save. If someone wants to grab an older nib with the browser window in it and see if swapping it in fixes the problem, that would be pretty conclusive. If nobody does it by the time I have time I'll try it.
Although only nib of 2004-11-4 build was overwritten to the newest build, scroll speed has not improved. I think that a cause is in other places.
this could be bug 243726 that regressed it.
Hmm... The change to the childCovers optimization _could_ have affected scrolling, I guess. We used to check whether the view covered the region even for cases when it was set to aIgnoreWidgetView. But with the change, we should still be doing that, no? We're looking at the child widgets and all that. Could the problem be that there are times when aIgnoreWidgetView doesn't have a corresponding widget? That is, do all scrolling things have widgets? If not, and if we used to treat them as covering anyway, we could have stopped doing that as a result of the changes in bug 243726...
The point is, someone should take a current build and see what the dirty region looks like while scrolling... Do we have paint flashing in Camino? If not, perhaps putting some printfs in the code or tracing in a debugger would work..
(In reply to comment #12) > The point is, someone should take a current build and see what the dirty region > looks like while scrolling... Do we have paint flashing in Camino? If not, > perhaps putting some printfs in the code or tracing in a debugger would work.. Quartz Debug will allow one to do this; I'll take a look with the latest nightly once I'm at a good stopping point in my work, if no one beats me to it.
I tested by backing out the changes committed for bug 243726. That is indeed what is causing this problem.
This is really irritating. Do we want to make an argument for backing out the offending patch or does somebody want to try to fix the new problem? The patch is a big one, which makes it harder to back out... Does anybody have an idea of what the problem is? Geoff? Boris? If anybody has any thoughts it would help people who are willing to fix the problem.
I've got some good news and some bad news. The bad news is that I really hate to back out patches that break only Mac. Because that means Mac problems are slowing down overall progress, and Mac simply isn't important enough strategically to justify that during alpha-stage development, in my opinion. The good news is that within a couple of months I expect to have a Mac at home and be doing some Mozilla development on it, so you should expect earlier detection and resolution of Mac-specific problems like this one.
Josh, could you test a build with the patch for bug 268090 in it? It could have conceivably helped here (though if it did, I'll be somewhat surprised). For the rest, if someone could answer the questions I asked in comment 12 that would maybe help...
I'm not sure how, but it seems for me that this problem has been resolved in the 2004-11-19 Nigtly Build. Can anyone confirm this?
Yes. There is a big difference in scrolling speeds between the Nov 18th and Nov 19th builds.
That scroll speed is improved by 2004-11-19 checked. Mac OS X 10.3.6 2004111908 (v0.8+)
Confirming that this is fixed as of Nov. 19 9:30 Central Time in a CVS build. Reopen later if the problem persists, but I don't think it will come back related to this patch. Thanks to whoever fixed it.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
So... 1) It sounds like the patch to bug 268090 fixed this 2) Why this would have made things _faster_, I have no idea. That patch removed extra optimization that we should not have been doing!
Depends on: 268090
Boris: 1) The patch for some reason re-enabled accelerated scrolling. 2) No idea. 3) the answer to your question in #12 is that Camino's scrolling with regard to the repaint region has been broken forever. I'm not sure of a good way to get a screenshot but if you look at it on a Mac with Quartz Debug's "flash screen updates yellow" checked, you can see it's usually not painting a normal pattern (which should be just the new material exposed by the scroll). See also bugs #164234 (WONTFIX) and #246998. Compare this with the way Safari or most any other app draws. If it draws normally use the browser for a few minutes and try again, on my machine just loading this bug page produces the behavior. Firefox repaints the entire view region (so no hardware acceleration) which is similar to the way Camino was acting when this bug was filed, which sucks but at least isn't broken. I use Firefox now but check in on Camino now and then, I only have access to this account when using Camino thanks to the Keychain support, no idea what the actual password is anymore, the email address is long dead.
Unfortunately I don't have a way to run Camino, yet. Like Robert, I should be able to do it within the next few months... Perhaps at that point we can make some progress on nsIWidget and its implementations. :(
You need to log in before you can comment on or make changes to this bug.