Create scroll bar primitives during display list construction.

[gw3583]

WebRender provides an API for creating scroll bar primitives implicitly, if enabled. In hindsight, this API is a mistake.

The scroll bars are not very customizable (either visual or behavior). It introduces significant code complexity in WR that makes some current implementation work difficult.

Gecko doesn't use this functionality at all - scroll bars are implemented as normal primitives in the display list.

For the reasons above, I'd like to remove scroll bar APIs from WR, and have them implemented in Servo similarly to how they are done in Gecko.

[gw3583]

@jdm @paulrouget Thoughts? Do you have objections to me removing the scroll bar implementation from WR before support was added into Servo to draw them?

[gw3583]

FWIW, I just built current Servo and the existing scrollbars don't seem to work correctly anyway - they clip out on one page, didn't appear at all on another page, and flicker / change size incorrectly on the third page.

[gw3583]

They're also not clickable / draggable when they are implemented in WR.

[pcwalton]

I have no objections to removing that support.

[paulrouget]

I think that makes sense.

[gw3583]

Some rough guidelines on how to implement this in Servo below.

During display list building, you need to add a primitive that represents the scroll bar. This can be a normal rectangle, can have whatever clips you desire etc. It can also be an image, if you want to use native OS scrollbar styles etc.

There are two parts:
(a) Working out where to position the scrollbar primitive.
(b) Adding it to the correct part of the display list.

For (a) you can either track the current scroll location inside layout / compositor, or you can call the WR API GetScrollNodeState. This will return the current local space offset of a given scroll frame.

Long term, you'll want to add scroll bars for any scroll frame, but the existing implementation only works on the main scroll frame anyway, so implementing that first would be a good step.

For (b) you can start with just adding the primitive to the root stacking context, as the last primitive added. This will ensure it doesn't scroll with the scroll frame itself, and is drawn after everything else. Supporting child scroll frames is similar - add the primitive to the stacking context that establishes the scroll root, not inside the scroll frame itself.

Please ping me if you need more information!

[hardBSDk]

Any update on the visible scrollbars support?