[Webkit-unassigned] [Bug 78872] [chromium] ScrollbarLayerChromium/CCScrollbarLayerImpl for CC-side scrollbar painting

[bugzilla-daemon at webkit.org]

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





--- Comment #25 from Tien-Ren Chen <trchen at chromium.org>  2012-03-01 20:21:56 PST ---
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > (In reply to comment #20)
> > > > (In reply to comment #19)
> > > > > > Source/WebCore/platform/graphics/chromium/ScrollbarLayerChromium.h:48
> > > > > > +    RefPtr<Scrollbar> m_scrollbar;
> > > > > 
> > > > > this seems very wrong. the layer shouldn't have any ownership concern with the scrollbar.
> > > > 
> > > > the alternative would be copying everything when creating ScrollbarLayerChromium.
> > > 
> > > I find this won't work. m_visibleSize and m_totalSize is something very dynamic, we need to update their value on every commits.
> > > I think we might be able to get these information from the layer data, any suggestion?
> > 
> > These are asking about the visible / total size of the scrollable area, not the scrollbar itself.  I think you should get those from the CCLayerImpl that's actually scrolling by giving the CCScrollbar (or CCScrollbarLayerImpl) a weak pointer to the CCLayerImpl that scrolls.  For example, totalSize() is some combination of the CCLayerImpl's maxScrollPosition, bounds, etc.
> > 
> > Keep in mind that these values can change on the thread without us going through a commit - for example, if the page scale changes due to a pinch gesture that changes the max scroll position and thus the totalSize() value. I think the only way to stay sane with these updates is to always query the value from the scrolling layer and not try to proactively sync them to other objects.
> 
> Ok, I managed to get all the values. (for totalSize again we use m_scrollLayer->children()[0]->contentBounds() hack)
> 
> However I observed that the scroll maximum is not 100% identical to the main-side. The impl-side scroll maximum is slight smaller than the main-side on http://www.nytimes.com/ This can be easily reproduced using arrow-key scroll (slow) and mouse-wheel scroll (fast).

NVM. Can no longer reproduce this after merging to latest tree.

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