Closed Bug 268218 Opened 20 years ago Closed 20 years ago

Scrolling on all pages is slow and jerky: builds 20041105 and after

Categories

(Camino Graveyard :: General, defect, P1)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino0.9

People

(Reporter: mozilla, Assigned: mikepinkerton)

References

Details

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.
Target Milestone: --- → Camino0.9
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...
Blocks: 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: 20 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.