Closed Bug 529557 Opened 13 years ago Closed 13 years ago

Scrolling in Feedly looks bad


(Core :: Layout, defect)

1.9.2 Branch
Windows 7
Not set



Tracking Status
status1.9.2 --- beta5-fixed


(Reporter: rcampbell, Assigned: roc)


(Blocks 1 open bug)



(1 file)

In Firefox version 3.6b3, install Feedly (available on AMO). Make sure you're using the "wide" view (make the browser wide enough so Feedly displays the sidebar with categories on the left). With Smooth Scrolling enabled, scroll slowly. See the screen dooring effect.
Flags: blocking1.9.2?
Hi Rob. 

Thank you very much for loging this bug. The scrolling performance issue in feedly 2.8 (version available in AMO) was caused by the use of -moz-box-shadow. You can see for more details.

We have been able to work around this problem by not using -moz-box-shadow. Work around is included in the 2.9 version which is currently being reviewed by the AMO editor team.

Will right a blog post to warn other developers about the impact of -moz-box-shadow on scrolling until this bug get fixed.

hi Ed,

We just tested this locally removing the -moz-box-shadow rules and still had the same scrolling issue. Jeff's current hunch is that it has something to do with the fixed side-panel. We'll post more as we find it.
I've put up a striped down version here:

It looks like this has to do with the fixed text on the left. In Firefox 3.5 there is tearing at the bottom of the list, but in 3.6 the tearing happens over the entire list.
Hi Jeff. Nice to meet you. What do you mean by tearing? Is there anything we can do on our side by modifying the markup?
well, I think the point is actually fixing the rendering issue we're seeing with this particular markup rather than hiding it. I want my feedly to look good on windows in 3.6! :)
Understood. Please let us know if there is anything else we can do to help reduce the size of the test case (or anything else!)
The version at:

makes the problem more obvious.

Are the individual labels on the right side "position: fixed"?. If you make the whole block "position: fixed" the problem might go away.
Assignee: nobody → roc
The individual labels are not position: fixed. Only the feedlyTabs element is fixed.

This looks like bug 529092.
Depends on: 529092
maybe it is, but the badness really springs from the fact that in some circumstances we're blitting like 86 separate rectangles for a single scroll operation. I'm still trying to figure out why.
OK, so the scroll analysis in ComputeRepaintRegionForScroll finds that all the text isn't moving and needs to be repainted. (It doesn't really, because it's over a gray background, but the visibleRegionOfMovingContent is larger than it should be ... maybe I should fix that, but you could easily modify this testcase so that the text actually did need to be repainted.) This creates a complex aRepaintRegion, which leads to an even more complex aBlitRegion.

I suppose we should simplify aRepaintRegion outward whenever we can do that without adding much area to it.
We probably do need to fix bug 529092 as well :-(
Component: Graphics → Layout
QA Contact: thebes → layout
Edwin, can you file a separate bug about performance issues related to -moz-box-shadow, if you can reproduce the problem on trunk and haven't already filed such a bug? It's no doubt a separate issue.
This patch reimplements nsRegion::SimplifyOutward to be a lot more intelligent. We coalesce rectangles in a way that tries to minimize the area that's added to the region. (It doesn't actually minimize, but it does pretty well.) Then we call SimplifyOutward on aRepaintRegion to bound the complexity of that region, which reduces the complexity of the blit region.

It reduces the screen-door effect on Windows, but doesn't eliminate it. Karl's right, we need to fix 529092.
(In reply to comment #14)
> Edwin, can you file a separate bug about performance issues related to
> -moz-box-shadow, if you can reproduce the problem on trunk and haven't already
> filed such a bug? It's no doubt a separate issue.

That might be bug 509052, which is filed for Mac, but looks like the same code is used for NT.
Can we get a blocking decision, here? Smooth scrolling isn't on by default, so I'm having a hard time saying that it's a hard release blocker, as opposed to a sucky one :(
it's definitely a regression from 1.9.1 which might help inform that decision.
If you guys decide not to fix it, is there a work around?
Note: Robert: Karl is right the -moz-box-shadow part of the bug appears on both windows and mac and is identical to bug 509052. I will update that bug with the safari information you requested.
I think you could work around it by giving the position:fixed element a solid background.
Hi Robert. Tried the "solid background" work around using 3.6 beta 3 and it does not seem to make a difference. Does it depend on the region simplification? Should I try it on another build?
Not blocking as it's not a default option, do want a fix, though.
blocking2.0: --- → ?
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
I've been using Feedly on my windows PC this morning and I have noticed that this issue is present without autoscrolling enabled. We may want to reconsider blocking status.
Flags: blocking1.9.2- → blocking1.9.2?
correction: without _smooth_scrolling enabled.
OK, I've got a fix for bug 529092 which makes this go away.
Whiteboard: [depends on bug 529092]
Blocks: 527728
Thank you very much Robert. Next time you are in the bay area, drinks will be on us!
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2+
Fixed by checkin for bug 529092.
blocking2.0: ? → ---
Whiteboard: [depends on bug 529092]
marking fixed.
Closed: 13 years ago
Resolution: --- → FIXED
and verified in Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b5pre) Gecko/20091201 Namoroka/3.6b5pre (.NET CLR 3.5.30729) ID:20091201044929

You need to log in before you can comment on or make changes to this bug.