Closed
Bug 925656
Opened 11 years ago
Closed 7 years ago
[B2G][Browser] Content of webpage shows up slowly while swiping around the page.
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: vlin, Unassigned)
References
Details
(Keywords: perf)
Attachments
(3 files)
Steps to reproduce:
1. open browser,enter a website address and go
2. "after the webpage loaded", zooming the webpage
3. swiping around the page
Actual results:
The webpage shows up slowly and background color will be shown before the content.
Expected results:
The webpage will show up seamlessly.
Reporter | ||
Updated•11 years ago
|
Component: General → Graphics
Product: Boot2Gecko → Core
Reporter | ||
Comment 1•11 years ago
|
||
Partner reported this issue on V1.1. We can also easily reproduce it on V1.2 or latest master, especially on high display resolution device.
It seems the invisible part of webpage will be cleaned up and repainted again while becomes visible.
Looks like a performance issue on content rendering ?
Is there any ongoing Bug related to this one ?
Flags: needinfo?(bgirard)
Reporter | ||
Comment 2•11 years ago
|
||
I found the latency is often too long(>10ms) here. It seams UI thread can't digest the task in time.
http://dxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp#l498
Here are my locally-appended logging points.
10-14 05:37:28.272: I/Gecko(8846): APZC: Call GeckoContentController::RequestContentRepaint
@ http://dxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/AsyncPanZoomController.cpp#l1022
10-14 05:37:28.272: I/Gecko(8846): APZC: Receive RequestContentRepaint@RemoteContentController then call DoRequestContentRepaint
@ http://dxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp#l498
10-14 05:37:28.282: I/Gecko(8846): APZC: Receive DoRequestContentRepaint
@ http://dxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp#l606
Reporter | ||
Comment 3•11 years ago
|
||
Something wrong with dumped captured.sym.
Opening browser.sym is fine.
Reporter | ||
Comment 4•11 years ago
|
||
It shows Browser's Paint() takes 1221.7 ms after receiving B2G's SendUpdateFrame() call here.
http://mxr.mozilla.org/mozilla-central/source/layout/ipc/RenderFrameParent.cpp#608
Paint() was dominated by DrawBufferWithRotation(), PlatformAllocSurfaceDescriptor() and DrawThebesLayer(). The root cause of this issue might be the same as Bug 920921.
Comment 5•11 years ago
|
||
The APZC should be pre-rendering content outside the screen and make this less obvious. Kats would know the latest state of the APZC in the b2g browser.
Flags: needinfo?(bgirard) → needinfo?(bugmail.mozilla)
Comment 6•11 years ago
|
||
From the video it looks like there is almost no displayport being used here. Is this reproducible on other pages too or just this one? It would help to get the checkerboard visualization tool up and running again to better see what's going on here and determine if the displayport heuristics need fixing.
Depends on: 927954
Flags: needinfo?(bugmail.mozilla)
Comment 7•7 years ago
|
||
Closing as we are not working on Firefox OS anymore.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•