Build mozilla trunk for Linux ARM environment Prepare ARM device (300-400MHz, N800) with profiling (oprofile) Open some not very small page, like wikipedia.org/linux.org.ru Make full page zoom (ex: 100% to 120%)... EXPECTED OUTCOME: Page zoomed for ~1 second ACTUAL OUTCOME: Page zoomed for ~5-6 second PS: Zooming of the same page on OQO Mobile, Windows takes about ~1 sec.
Profile URL: jar:https://bugzilla.mozilla.org/attachment.cgi?id=287414!/dmg/test.txt
Nothing jumps out at me as an obvious bug. Can you get line number information to see where the samples in nsLineLayout::ReflowFrame are landing?
Created attachment 288189 [details] Profile data in Jprof format Linux, 800MHz. Normal pango font rendering Zoom from 100% to 120%
Created attachment 288191 [details] ENABLE_FAST_PATH_ALWAYS=1 Profile data Same testcase but with enabled fast path always ENABLE_FAST_PATH_ALWAYS=1
Over half the time is under pango_fc_font_map_get_type. Most of that is actually under FcFontSort. And a lot of that is destroying the old font set and charset (with some actual qsort tossed in)... Top-down, we seem to have one obvious inefficiency: DocumentViewerImpl::SetFullZoom calls nsPresContext::SetFullZoom, which calls nsViewManager::DoSetWindowDimensions, which does a resize reflow on the presshell. That takes up about 25% of the profile. Then immediately after that we call ClearStyleDataAndReflow(), which blows away all our style, reresolves it, then generally reflows the world. 50% of the profile is this second reflow. We really shouldn't be doing both reflows, imo. Fixing that would help performance everywhere, not just on ARM. We might want to file separate bugs for the actual work and use this as a tracking bug... in that case, please move the 1.9 nomination to the bug about the two reflows.
As I understand after landing bug 362682 it begins to work ~ 2x slower (related to pango_fc_font_map_get_type profile entries)
Depends on: 403660
Filed bug 403660 for bz's issue, and marked that one as blocking+; minusing this one.
Flags: blocking1.9? → blocking1.9-
Don't have profile data for last measurement... but here is results for last trunk seamonkey comparing with Opera 9.25. 1.86GHz, ATI, fglrx, HW composite enabled. Wikipedia page loading: (Mozilla - 20.5 s) vs (Opera - 10 s) Wikipedia zoom+ (100 - 120): (Mozilla - 16.2 s) vs (Opera - 5.1 s)
>>DocumentViewerImpl::SetFullZoom calls nsPresContext::SetFullZoom, which calls >>nsViewManager::DoSetWindowDimensions, which does a resize reflow on the >>presshell. That takes up about 25% of the profile. Then immediately after >>that we call ClearStyleDataAndReflow(), which blows away all our style, >>reresolves it, then generally reflows the world. 50% of the profile is this >>second reflow. >>>In Second reflow: ClearStyleDataAndReflow() calls ComputeStyleChangeFor() and >>>it in turn calls ReResolveStyleContext(). ReResolveStyleContext() is >>>actually taking more than 60% of whole time to render CSS/data recomputation. >>>I think optimizing the operations in this function will improve performance >>>of zooming a lot. After looking at source ReResolveStyleContext() function and analyzing the time taken when a page is zoomed in from 100% to 150% found that do-while loop in nsFrameManager.cpp at line 1332 is blocking execution control for some time for listIndex = 1 with child value null. There is some problem in that do-while. Does anyone know what exactly the do-while in function is doing on page zoom? I think customizing the ReResolveStyleContext()function wrto fullzoom will solve problem of low performance on Linux ARM.
> listIndex = 1 with child value null I assume you mean listname null? > Does anyone know what exactly the do-while in function is doing on page zoom? It's recomputing style on everything in the page. I thought I said that in response to your comment in bug 403660? The null list name are the "in flow" children, in CSS parlance. That would be pretty much everything. > I think customizing the ReResolveStyleContext()function wrto fullzoom How exactly? We could perhaps skip recomputation of style structs that don't depend on the appunit-to-pixel ratio, but there may not be all that many of them to start with, and this is pretty fragile (e.g. if another member gets added to a style struct). Put another way, not actually zooming would be faster than zooming. But it's not really a solution. ;)
I'm going to call this one INCOMPLETE as it hasn't received attention in 4 years and a lot has changed in this space. Reopen if needed.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
I really doubt much has changed here, actually. Have you tried to reproduce?
Ok, I haven't. CC'ing some mobile gfx people.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
More examples of slow page zoom here: https://bugzilla.mozilla.org/show_bug.cgi?id=645900
You need to log in before you can comment on or make changes to this bug.