Slow full page zooming on wikipedia, Linux/ARM

REOPENED
Unassigned

Status

()

Core
Graphics
REOPENED
11 years ago
6 years ago

People

(Reporter: romaxa, Unassigned)

Tracking

({perf})

Trunk
ARM
Linux
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 287414 [details]
Profile data for testcase wikipedia
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?
(Reporter)

Comment 4

11 years ago
Created attachment 288189 [details]
Profile data in Jprof format

Linux, 800MHz.
Normal pango font rendering
Zoom from 100% to 120%
(Reporter)

Comment 5

11 years ago
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.
Flags: blocking1.9?
(Reporter)

Comment 7

11 years ago
As I understand after landing bug 362682 it begins to work ~ 2x slower (related to pango_fc_font_map_get_type profile entries)
(Reporter)

Updated

11 years ago
Depends on: 403618
Filed bug 403660 for bz's issue, and marked that one as blocking+; minusing this one.
Flags: blocking1.9? → blocking1.9-
(Reporter)

Comment 9

11 years ago
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)

Comment 10

11 years ago
>>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.  ;)

Updated

11 years ago
Keywords: perf
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 → ---

Comment 15

7 years ago
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.