[Webkit-unassigned] [Bug 91688] [chromium] Add CCScrollbarAnimationController class for compositor scrollbar animation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=91688





--- Comment #18 from Tien-Ren Chen <trchen at chromium.org>  2012-07-30 15:25:35 PST ---
(In reply to comment #17)
> (In reply to comment #13)
> > I think we want to verify that the scrollbar will show in responding to the user gesture, and will eventually fade out as time goes. Is there a good way to simulate monotonicallyIncreasingTime()?
> 
> I'm not sure I understand what the problem is. You should just be able to pass arbitrary monotonically increasing time values to functions that need them.

That's a reasonable way to do it, but will make the client code very awkward. For example, CCLayerImpl doesn't have any dependency to monotonicallyIncreasingTime, however CCLayerImpl::scrollBy needs the timestamp to pass it to CCScrollbarAnimator::updateScrollOffset. If we let CCLayerImpl to generate the timestamp, now it's the CCLayerImpl becomes un-testable. Or again we can require the client of CCLayerImpl to pass in the current timestamp... There is just no end to this.

I think it is not a bad assumption to have only one global monotonic clock singleton, and who ever needs it just generate it instead of requiring the client to pass it in. Just that we need a way to mock the monotonic clock in unit tests.

(In reply to comment #16)
> (From update of attachment 155376 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=155376&action=review
> 
> > Source/WebCore/page/FrameView.cpp:655
> > +// On Android (and potentially other platform that supports pinch zoom)
> > +// the main frame should always create scrollbars unless hidden explicitly,
> > +// as the viewport size can change in the compositor
> > +#if OS(ANDROID)
> > +    if (m_frame->page()->mainFrame() == m_frame) {
> > +        if (hMode == ScrollbarAuto)
> > +            hMode = ScrollbarAlwaysOn;
> > +        if (vMode == ScrollbarAuto)
> > +            vMode = ScrollbarAlwaysOn;
> > +    }
> > +#endif
> 
> I thought this was going into a separate patch?

Ah I forgot to add -g option when preparing the patch. Let me re-upload it.

> > Source/WebCore/rendering/RenderLayer.cpp:2961
> > -    if (!isSelfPaintingLayer() && !hasSelfPaintingLayerDescendant())
> > +    if (!isSelfPaintingLayer() && !hasSelfPaintingLayerDescendant() && !(paintFlags & PaintLayerPaintingOverlayScrollbars))
> 
> Where did all these RenderLayer changes come from in this latest patch?

Same as above. It is another patch to solve an issue with main thread side overlay scrollbar rendering.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.