Regression: Pages take longer to show initially than they did with Fennec Beta 5

Assigned to



Widget: Gtk
9 years ago
8 years ago


(Reporter: Stuart Parmenter, Assigned: karlt)


1.9.2 Branch
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 final-fixed)


(Whiteboard: [fennec-needs])


(2 attachments)



9 years ago
If you do a side-by-side comparison of beta 5 versus trunk, you'll see that beta 5 shows the page content much faster than we do now.  This may be a platform problem, but having trouble identifying it.


9 years ago
tracking-fennec: --- → 1.0+
The regression seems to be on 12/16's nightly build. Progressive rendering is still going on, but performance has gone down quite a bit. Here's a list of bugs set to resolved:fixed during that time period;query_format=advanced;chfield=bug_status;chfieldfrom=2009-12-15;chfieldvalue=resolved;resolution=FIXED;product=Fennec
There's two bugs here:

1. The regression range found on 12/16 was for the degredation of performance of chrome during page load.

2. I found another regression range between 12/13-12/16 for the long wait time to have content shown on the screen initially during page load.
Bug was created for the issue associated with #1 in comment #2
Created attachment 418296 [details]
First mozafterpaint log

These numbers correspond with the regression we've seen for loading.  I tried nytimes with the permutations {xulrunner,fennec} X {b5 version, tip version}.

I am rather convinced this problem is somewhere in platform.

Comment 5

8 years ago
This is a regression from 509278

Comment 6

8 years ago
Created attachment 418952 [details] [diff] [review]

Comment 7

8 years ago
Comment on attachment 418952 [details] [diff] [review]

I wonder if we should just remove this code entirely for all platforms?
Attachment #418952 - Flags: review?(karlt)


8 years ago
Component: General → Widget: Gtk
OS: Windows 7 → All
Product: Fennec → Core
QA Contact: general → gtk
Hardware: x86 → All
Summary: Regression: Pages take longer to show initially than they did with beta 5 → Regression: Pages take longer to show initially than they did with Fennec Beta 5


8 years ago
Flags: blocking1.9.2?

Comment 8

8 years ago
<stuart> basically the problem is that compared with a build from before,
         there is a 5-15 second delay in initial paint

Initial paint of content IIUC.
What is shown before the initial paint?
Previous content?
Or fill content provided by the front end?
Or the background of the GTK theme?
Or garbage?

Comment 9

8 years ago
Comment on attachment 418296 [details]
First mozafterpaint log

>    (begin) : on location change 
>    655 : mozafterpaint 

Time from js window location change to first MozAfterPaint event?
Is the unit ms?
Is there only one MozAfterPaint event?
Is this for invalidation of the frontend document or of the content document?

>    (begin) : on location change 
>    124 : mozafterpaint

Is this another sample (of the same test)?


8 years ago
Blocks: 509278

Comment 10

8 years ago
Comment on attachment 418952 [details] [diff] [review]

I'm OK if you'd like to land this as a workaround for now, given that we don't really understand what is happening and we won't be worse off than before the change from bug 509278.

However, this is not ideal so I don't want to do this on all platforms, and
I'd still like to know the answers to the above questions as they may help
understand how to fix this properly.

AFAIK, the only effect from Show()ing and already Show()n window is to
invalidate the whole window.

* This will cause unnecessary painting.

* It suggests that a well-placed Invalidate() (or perhaps Update()) would be
  enough and possibly cause content to appear earlier than happens with the
  extra Show(), whose caller was not intending to invalidate (so may not have
  called this at the appropriate time).
Attachment #418952 - Flags: review?(karlt) → review+
Flags: blocking1.9.2? → blocking1.9.2+
Whiteboard: [fennec-needs]
I've pushed this to 1.9.2. I think we can just leave this bug open for a better trunk fix.
status1.9.2: --- → final-fixed
Perhaps it's better to push it to trunk too, just so it doesn't get forgotten and then produce an unexplained regression when switching to a later branch?

Comment 13

8 years ago
handing this over to karl to find best solution for the regression
Assignee: nobody → karlt
Is this blocking 1.0 now, stuart?
(In reply to comment #14)
> Is this blocking 1.0 now, stuart?

No, and it's not blocking 1.1 either
tracking-fennec: 1.0+ → ---
You need to log in before you can comment on or make changes to this bug.