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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: vlin, Unassigned)

References

Details

(Keywords: perf)

Attachments

(3 files)

Attached video IMG_2149.MOV
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.
Component: General → Graphics
Product: Boot2Gecko → Core
Blocks: 921002
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)
Keywords: perf
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
Attached file Gecko profiler
Something wrong with dumped captured.sym. Opening browser.sym is fine.
Attached image Android profiler
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.
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)
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)
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.

Attachment

General

Created:
Updated:
Size: