Closed
Bug 605189
Opened 14 years ago
Closed 13 years ago
[d2d]Autoscroll is lagged painfully
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
mozilla2.0
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: alice0775, Assigned: bas.schouten)
References
()
Details
(Keywords: perf)
Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101018 Firefox/4.0b8pre ID:20101018043251
Autoscroll is lagged.
if disabled d2d, autoscroll The autoscroll is lagged, but I can allow it.
OR
if hide Autoscroll marker by CSS, The autoscroll is lagged, but I can allow it.
#autoscroller
{
visibility: collapse;
}
Reproducible: Always
Steps to Reproduce:
1. Start Minefield with new profile
2. Open URL ( http://www.msnbc.msn.com/id/39715022/ns/world_news-americas/ )
3. Wait till throbber of the tab stops
4. Scroll bottom and top of page by scroll bar once (due to Bug 605127)
5. Start autoscroll by Middle button.(Scroll page not so fast)
Actual Results:
Autoscroll is lagged painfully
Expected Results:
Autoscroll is smoothly
Regression window:
Works(But autoscroll marker do not appear.)
http://hg.mozilla.org/mozilla-central/rev/11aa64d1d612
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100621 Minefield/3.7a6pre ID:20100621175114
Fails(lagged painfully):
http://hg.mozilla.org/mozilla-central/rev/1cec9ed81981
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100621 Minefield/3.7a6pre ID:20100621193612
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=11aa64d1d612&tochange=1cec9ed81981
Candidate bug:
Bug 573507 - [D2D] Make Direct2D support transparent windows
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
While maybe not totally related, setting the pref:
turning off layers.accelerate-all to none
will clear the hang/lag when scrolling.
Reporter | ||
Comment 2•14 years ago
|
||
In my case, turning off layers.accelerate-all, nothing changes.
Assignee | ||
Comment 3•14 years ago
|
||
Hrm, it's not unfeasible the readback is problematic for D2D. We may just want to disable D2D on transparent windows. FWIW I can't really reproduce the problem.
Reporter | ||
Comment 4•14 years ago
|
||
The scroll lag happens around paragraph of "Video: Miners share incredible tales of survival" and "Discuss: Cracks appear in Chile miners' 'pact of silence'"
The following is screen capture movie.(MS media encoder can not capture autoscroll marker.)
http://www.youtube.com/watch?v=uEqCEVznBmg
Reporter | ||
Comment 5•14 years ago
|
||
Because the video of comment 4 is not the good result,
I show a link again.
http://www.youtube.com/watch?v=BZi0rnEAKbY
Reporter | ||
Comment 6•14 years ago
|
||
In local build:
Build from 1aa5e909f473: scroll lagged
Build from e64d6eefbce9: scroll *NOT* lagged
the following causes this.
1aa5e909f473 Bas Schouten — Bug 573507: Make D2D work with transparent (layered) windows by using interop to get a DC from. r=jmathies
Assignee | ||
Comment 7•14 years ago
|
||
Interesting! I'm not sure if this blocks 2.0, maybe it does. We should probably fix it though. I wonder why it's so slow.
Comment 8•14 years ago
|
||
Let's block for now, because this is the default middle mouse/mousewheel action. We can re-evaluate later if we need to.
Assignee: nobody → bas.schouten
blocking2.0: ? → final+
Comment 9•14 years ago
|
||
while its not related to scrolling, this site seems to exhibit the same drag on the UI and consumes tons of CPU:
https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
Comment 10•14 years ago
|
||
Uses from 30-40% CPU on my i7 Core Quad. Really slow.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre - Build ID: 20101021113531
Comment 11•14 years ago
|
||
That is probably the problem we currently have with wmode=transparent Flash objects.
Comment 12•14 years ago
|
||
(In reply to comment #9)
> while its not related to scrolling, this site seems to exhibit the same drag on
> the UI and consumes tons of CPU:
>
> https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
related to this? https://bugzilla.mozilla.org/show_bug.cgi?id=579597
Comment 13•14 years ago
|
||
(In reply to comment #9)
> while its not related to scrolling, this site seems to exhibit the same drag on
> the UI and consumes tons of CPU:
>
> https://genographic.nationalgeographic.com/genographic/lan/en/globe.html
With the landing of asyn-layers today, using the latest hourly, the hang is somewhat is improved, but the national geographic site still consumes tons of CPU.
The MSNBC link in the URL no longer lags when scrolling, but still consumes some CPU even when NOT playing.
Comment 14•14 years ago
|
||
(In reply to comment #13)
> The MSNBC link in the URL no longer lags when scrolling, but still consumes
> some CPU even when NOT playing.
Could be that its downloading data over the network if you take a peak at the windows 7 resource monitor.
Comment 15•14 years ago
|
||
I've noted that turning off OOPP re-introduces the lag that went away as I noted in comment #13. CPU load is still there even with OOPP 'off'.
Comment 16•14 years ago
|
||
This is apparently improved by async plugin layers; we don't need to block on it.
blocking2.0: final+ → -
Assignee | ||
Comment 17•13 years ago
|
||
I don't think this still exists in the current plugin rendering code, at least not to the extent that it's a bug, please re-open if I'm wrong.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•