Closed Bug 900094 Opened 9 years ago Closed 6 years ago

severe scroll jank


(Core :: SVG, defect)

23 Branch
Not set





(Reporter: fb+mozdev, Unassigned, NeedInfo)


(Blocks 1 open bug, )


(Keywords: perf, Whiteboard: [in-the-wild] [external-report])

Visit and scroll. Janky as hell.
Keywords: perf
Florian have you tested with the latest Nigthly?

I've tested both with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 buildID :20130730113002
and with the Nightly 26.0a1 (2013-08-06) it seems to me to be significantly more efficient in the Nightly.
Flags: needinfo?(fb+mozdev)
Aurora 25.0a2 (2013-08-10) and Nightly 26.0a1 (2013-08-10) is way better, however it still feels laggy sometimes.
Flags: needinfo?(fb+mozdev)
Component: Untriaged → SVG
Product: Firefox → Core
Blocks: 100951
So I tried with the patch from Bug 764299 (Try: OS X 10.7 opt build x64: and did not see any improvements (subjectively) on my machine (MBA'12) on the URL provided, however scrolling on the front page is much smoother. 

The following things may contribute to the remaining scrolling jank: 
– Shadows (the links have a text-shadow)
– Custom fonts (text & headings)
– JS (the comment section)
– SVG, gradients (theoretically)
Depends on: 764299
I've taken some measurements based on the patch from bug 764299 and have concluded that there _is_ improvement, it's just still slow. =) Here are the numbers in milliseconds:

> Original version of page:
>  Retina (1024 x 6689)
>    No cache: 25ms
>    With cache: 15ms
>  Non-retina (512 x 3344)
>   No cache: 7ms
>   With cache: 4ms
> With footer + disqus comments div removed:
>  Retina (1024 x 4111)
>    No cache: 28ms
>    With cache: 9ms
>  Non-retina (512x2055)
>    No cache: 7ms
>    With cache: 2.3ms

Note that there's a fair amount of variance for all of these measures (particularly the "no cache" version) but the trend I saw was pretty clear: we get speedup, but performance is still pretty awful. These are small window sizes, too. Things are even slower for larger window sizes; I could easily produce frame drawing times of 50ms with larger window sizes, which means we can't do better than 20fps. =\

The fundamental problem is that the background image on this page (an SVG) gets stretched across the whole page, which ends up making it _huge_. With such a monster image our drawing performance is not great, and I think we'll need a more sophisticated approach than caching alone to make it better.
When I say drawing times of 50ms, btw, I mean 50ms _just for the background SVG_. Those other factors you mention may also contribute but the background SVG all on its own is enough to produce awful scrolling performance when the window size is larger.
Blocks: 527728
Whiteboard: [in-the-wild] [external-report]
This specific SVG graphic has a ton of semi-transparent circles, which are probably responsible for slowing the graphic rendering speed.  Though, it shouldn't be so slow that prerendering and caching can't take care of the jank.
Seth, may you please remeasure with a current Nightly? Or tell me how I can get these numbers (though I only have an MBA'12 at hand)?
Ever confirmed: true
Flags: needinfo?(seth)
Seems smooth as butter to me, and paint flashing isn't showing any over invalidation.
Link is dead, but based on comment 9 closing this as WORKSFORME.
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.