402555 - Slow full page zooming on wikipedia, Linux/ARM

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Oleg Romashin (:romaxa)]

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.

Comment 1

[Oleg Romashin (:romaxa)]

Attachment: Profile data for testcase wikipedia

Comment 2

[Oleg Romashin (:romaxa)]

Profile URL:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=287414!/dmg/test.txt

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 4

[Oleg Romashin (:romaxa)]

Attachment: Profile data in Jprof format

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

Comment 5

[Oleg Romashin (:romaxa)]

Attachment: ENABLE_FAST_PATH_ALWAYS=1 Profile data

Same testcase but with enabled fast path always
ENABLE_FAST_PATH_ALWAYS=1

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[Oleg Romashin (:romaxa)]

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

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Filed bug 403660 for bz's issue, and marked that one as blocking+; minusing this one.

Comment 9

[Oleg Romashin (:romaxa)]

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

[venu madhav]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

> 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.  ;)

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

I really doubt much has changed here, actually.  Have you tried to reproduce?

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

Ok, I haven't. CC'ing some mobile gfx people.

Comment 15

[DB Cooper]

More examples of slow page zoom here:

https://bugzilla.mozilla.org/show_bug.cgi?id=645900