RenderSliver class

Base class for the render objects that implement scroll effects in viewports.

A RenderViewport has a list of child slivers. Each sliver — literally a slice of the viewport's contents — is laid out in turn, covering the viewport in the process. (Every sliver is laid out each time, including those that have zero extent because they are "scrolled off" or are beyond the end of the viewport.)

Slivers participate in the sliver protocol, wherein during layout each sliver receives a SliverConstraints object and computes a corresponding SliverGeometry that describes where it fits in the viewport. This is analogous to the box protocol used by RenderBox, which gets a BoxConstraints as input and computes a Size.

Slivers have a leading edge, which is where the position described by SliverConstraints.scrollOffset for this sliver begins. Slivers have several dimensions, the primary of which is SliverGeometry.paintExtent, which describes the extent of the sliver along the main axis, starting from the leading edge, reaching either the end of the viewport or the end of the sliver, whichever comes first.

Slivers can change dimensions based on the changing constraints in a non-linear fashion, to achieve various scroll effects. For example, the various RenderSliverPersistentHeader subclasses, on which SliverAppBar is based, achieve effects such as staying visible despite the scroll offset, or reappearing at different offsets based on the user's scroll direction (SliverConstraints.userScrollDirection).

Writing a RenderSliver subclass

Slivers can have sliver children, or children from another coordinate system, typically box children. (For details on the box protocol, see RenderBox.) Slivers can also have different child models, typically having either one child, or a list of children.

Examples of slivers

A good example of a sliver with a single child that is also itself a sliver is RenderSliverPadding, which indents its child. A sliver-to-sliver render object such as this must construct a SliverConstraints object for its child, then must take its child's SliverGeometry and use it to form its own geometry.

The other common kind of one-child sliver is a sliver that has a single RenderBox child. An example of that would be RenderSliverToBoxAdapter, which lays out a single box and sizes itself around the box. Such a sliver must use its SliverConstraints to create a BoxConstraints for the child, lay the child out (using the child's layout method), and then use the child's RenderBox.size to generate the sliver's SliverGeometry.

The most common kind of sliver though is one with multiple children. The most straight-forward example of this is RenderSliverList, which arranges its children one after the other in the main axis direction. As with the one-box-child sliver case, it uses its constraints to create a BoxConstraints for the children, and then it uses the aggregate information from all its children to generate its geometry. Unlike the one-child cases, however, it is judicious in which children it actually lays out (and later paints). If the scroll offset is 1000 pixels, and it previously determined that the first three children are each 400 pixels tall, then it will skip the first two and start the layout with its third child.


As they are laid out, slivers decide their geometry, which includes their size (SliverGeometry.paintExtent) and the position of the next sliver (SliverGeometry.layoutExtent), as well as the position of each of their children, based on the input constraints from the viewport such as the scroll offset (SliverConstraints.scrollOffset).

For example, a sliver that just paints a box 100 pixels high would say its SliverGeometry.paintExtent was 100 pixels when the scroll offset was zero, but would say its SliverGeometry.paintExtent was 25 pixels when the scroll offset was 75 pixels, and would say it was zero when the scroll offset was 100 pixels or more. (This is assuming that SliverConstraints.remainingPaintExtent was more than 100 pixels.)

The various dimensions that are provided as input to this system are in the constraints. They are described in detail in the documentation for the SliverConstraints class.

The performLayout function must take these constraints and create a SliverGeometry object that it must then assign to the geometry property. The different dimensions of the geometry that can be configured are described in detail in the documentation for the SliverGeometry class.


In addition to implementing layout, a sliver must also implement painting. This is achieved by overriding the paint method.

The paint method is called with an Offset from the Canvas origin to the top-left corner of the sliver, regardless of the axis direction.

Subclasses should also override applyPaintTransform to provide the Matrix4 describing the position of each child relative to the sliver. (This is used by, among other things, the accessibility layer, to determine the bounds of the child.)

Hit testing

To implement hit testing, either override the hitTestSelf and hitTestChildren methods, or, for more complex cases, instead override the hitTest method directly.

To actually react to pointer events, the handleEvent method may be implemented. By default it does nothing. (Typically gestures are handled by widgets in the box protocol, not by slivers directly.)

Helper methods

There are a number of methods that a sliver should implement which will make the other methods easier to implement. Each method listed below has detailed documentation. In addition, the RenderSliverHelpers class can be used to mix in some helpful methods.


If the subclass positions children anywhere other than at scroll offset zero, it should override childScrollOffset. For example, RenderSliverList and RenderSliverGrid override this method, but RenderSliverToBoxAdapter does not.

This is used by, among other things, Scrollable.ensureVisible.


Subclasses should implement childMainAxisPosition to describe where their children are positioned.


If the subclass positions children in the cross-axis at a position other than zero, then it should override childCrossAxisPosition. For example RenderSliverGrid overrides this method.

Implemented by




centerOffsetAdjustment double
For a center sliver, the distance before the absolute zero scroll offset that this sliver can cover. [...]
constraints SliverConstraints
The layout constraints most recently supplied by the parent.
geometry SliverGeometry
The amount of space this sliver occupies. [...]
read / write
paintBounds Rect
An estimate of the bounds within which this render object will paint. Useful for debugging flags such as debugPaintLayerBordersEnabled.
semanticBounds Rect
The bounding box, in the local coordinate system, of this object, for accessibility purposes.
alwaysNeedsCompositing bool
Whether this render object always needs compositing. [...]
@protected, read-only, inherited
attached bool
Whether this node is in a tree whose root is attached to something. [...]
read-only, inherited
debugCanParentUseSize bool
Whether the parent render object is permitted to use this render object's size. [...]
read-only, inherited
debugCreator ↔ dynamic
The object responsible for creating this render object. [...]
read / write, inherited
debugDoingThisLayout bool
Whether performLayout for this render object is currently running. [...]
read-only, inherited
debugDoingThisPaint bool
Whether paint for this render object is currently running. [...]
read-only, inherited
debugDoingThisResize bool
Whether performResize for this render object is currently running. [...]
read-only, inherited
debugLayer OffsetLayer
In debug mode, the compositing layer that this render object uses to repaint. [...]
read-only, inherited
debugNeedsLayout bool
Whether this render object's layout information is dirty. [...]
read-only, inherited
debugNeedsPaint bool
Whether this render object's paint information is dirty. [...]
read-only, inherited
debugSemantics SemanticsNode
The semantics of this render object. [...]
read-only, inherited
depth int
The depth of this node in the tree. [...]
read-only, inherited
hashCode int
The hash code for this object. [...]
read-only, inherited
isRepaintBoundary bool
Whether this render object repaints separately from its parent. [...]
read-only, inherited
layer OffsetLayer
The compositing layer that this render object uses to repaint. [...]
read-only, inherited
needsCompositing bool
Whether we or one of our descendants has a compositing layer. [...]
read-only, inherited
owner PipelineOwner
The owner for this node (null if unattached). [...]
read-only, inherited
parent AbstractNode
The parent of this node in the tree.
read-only, inherited
parentData ParentData
Data for use by the parent render object. [...]
read / write, inherited
runtimeType Type
A representation of the runtime type of the object.
read-only, inherited
sizedByParent bool
Whether the constraints are the only input to the sizing algorithm (in particular, child nodes have no impact). [...]
@protected, read-only, inherited


applyPaintTransform(RenderObject child, Matrix4 transform) → void
Applies the transform that would be applied when painting the given child to the given matrix. [...]
calculatePaintOffset(SliverConstraints constraints, { double from, double to }) double
Computes the portion of the region from from to to that is visible, assuming that only the region from the SliverConstraints.scrollOffset that is SliverConstraints.remainingPaintExtent high is visible, and that the relationship between scroll offsets and paint offsets is linear. [...]
childCrossAxisPosition(RenderObject child) double
Returns the distance along the cross axis from the zero of the cross axis in this sliver's paint coordinate space to the nearest side of the given child. [...]
childMainAxisPosition(RenderObject child) double
Returns the distance from the leading visible edge of the sliver to the side of the given child closest to that edge. [...]
childScrollOffset(RenderObject child) double
Returns the scroll offset for the leading edge of the given child. [...]
debugAssertDoesMeetConstraints() → void
Verify that the object's constraints are being met. Override this function in a subclass to verify that your state matches the constraints object. This function is only called in checked mode and only when needsLayout is false. If the constraints are not met, it should assert or throw an exception.
debugFillProperties(DiagnosticPropertiesBuilder description) → void
debugPaint(PaintingContext context, Offset offset) → void
Override this method to paint debugging information.
debugResetSize() → void
If a subclass has a "size" (the state controlled by parentUsesSize, whatever it is in the subclass, e.g. the actual size property of RenderBox), and the subclass verifies that in checked mode this "size" property isn't used when debugCanParentUseSize isn't set, then that subclass should override debugResetSize to reapply the current values of debugCanParentUseSize to that state.
getAbsoluteSizeRelativeToOrigin() Size
This returns a Size with dimensions relative to the leading edge of the sliver, specifically the same offset that is given to the paint method. This means that the dimensions may be negative. [...]
handleEvent(PointerEvent event, SliverHitTestEntry entry) → void
Override this method to handle pointer events that hit this render object.
hitTest(HitTestResult result, { double mainAxisPosition, double crossAxisPosition }) bool
Determines the set of render objects located at the given position. [...]
hitTestChildren(HitTestResult result, { double mainAxisPosition, double crossAxisPosition }) bool
Override this method to check whether any children are located at the given position. [...]
hitTestSelf({double mainAxisPosition, double crossAxisPosition }) bool
Override this method if this render object can be hit even if its children were not hit. [...]
performResize() → void
Updates the render objects size using only the constraints. [...]
adoptChild(RenderObject child) → void
Called by subclasses when they decide a render object is a child. [...]
assembleSemanticsNode(SemanticsNode node, SemanticsConfiguration config, Iterable<SemanticsNode> children) → void
Assemble the SemanticsNode for this RenderObject. [...]
attach(PipelineOwner owner) → void
Mark this node as attached to the given owner. [...]
clearSemantics() → void
Removes all semantics from this render object and its descendants. [...]
@mustCallSuper, inherited
debugDescribeChildren() List<DiagnosticsNode>
debugRegisterRepaintBoundaryPaint({bool includedParent: true, bool includedChild: false }) → void
Called, in checked mode, if isRepaintBoundary is true, when either the this render object or its parent attempt to paint. [...]
describeApproximatePaintClip(RenderObject child) Rect
Returns a rect in this object's coordinate system that describes the approximate bounding box of the clip rect that would be applied to the given child during the paint phase, if any. [...]
describeSemanticsConfiguration(SemanticsConfiguration config) → void
Report the semantics of this node, for example for accessibility purposes. [...]
@protected, inherited
detach() → void
Mark this node as detached. [...]
@mustCallSuper, inherited
dropChild(RenderObject child) → void
Called by subclasses when they decide a render object is no longer a child. [...]
getTransformTo(RenderObject ancestor) Matrix4
Applies the paint transform up the tree to ancestor. [...]
invokeLayoutCallback<T extends Constraints>(LayoutCallback<T> callback) → void
Allows mutations to be made to this object's child list (and any descendants) as well as to any other dirty nodes in the render tree owned by the same PipelineOwner as this object. The callback argument is invoked synchronously, and the mutations are allowed only during that callback's execution. [...]
@protected, inherited
layout(Constraints constraints, { bool parentUsesSize: false }) → void
Compute the layout for this render object. [...]
markNeedsCompositingBitsUpdate() → void
Mark the compositing state for this render object as dirty. [...]
markNeedsLayout() → void
Mark this render object's layout information as dirty, and either register this object with its PipelineOwner, or defer to the parent, depending on whether this object is a relayout boundary or not respectively. [...]
markNeedsLayoutForSizedByParentChange() → void
Mark this render object's layout information as dirty (like markNeedsLayout), and additionally also handle any necessary work to handle the case where sizedByParent has changed value. [...]
markNeedsPaint() → void
Mark this render object as having changed its visual appearance. [...]
markNeedsSemanticsUpdate() → void
Mark this node as needing an update to its semantics description. [...]
markParentNeedsLayout() → void
Mark this render object's layout information as dirty, and then defer to the parent. [...]
@protected, inherited
noSuchMethod(Invocation invocation) → dynamic
Invoked when a non-existent method or property is accessed. [...]
paint(PaintingContext context, Offset offset) → void
Paint this render object into the given context at the given offset. [...]
performLayout() → void
Do the work of computing the layout for this render object. [...]
@protected, inherited
reassemble() → void
Cause the entire subtree rooted at the given RenderObject to be marked dirty for layout, paint, etc, so that the effects of a hot reload can be seen, or so that the effect of changing a global debug flag (such as debugPaintSizeEnabled) can be applied. [...]
redepthChild(AbstractNode child) → void
Adjust the depth of the given child to be greater than this node's own depth. [...]
@protected, inherited
redepthChildren() → void
Adjust the depth of this node's children, if any. [...]
replaceRootLayer(OffsetLayer rootLayer) → void
Replace the layer. This is only valid for the root of a render object subtree (whatever object scheduleInitialPaint was called on). [...]
rotate({int oldAngle, int newAngle, Duration time }) → void
Rotate this render object (not yet implemented).
scheduleInitialLayout() → void
Bootstrap the rendering pipeline by scheduling the very first layout. [...]
scheduleInitialPaint(ContainerLayer rootLayer) → void
Bootstrap the rendering pipeline by scheduling the very first paint. [...]
scheduleInitialSemantics() → void
Bootstrap the semantics reporting mechanism by marking this node as needing a semantics update. [...]
setupParentData(RenderObject child) → void
Override to setup parent data correctly for your children. [...]
showOnScreen([RenderObject child ]) → void
Attempt to make this or a descendant RenderObject visible on screen. [...]
toDiagnosticsNode({String name, DiagnosticsTreeStyle style }) DiagnosticsNode
toString({DiagnosticLevel minLevel }) String
toStringDeep({String prefixLineOne: '', String prefixOtherLines: '', DiagnosticLevel minLevel: DiagnosticLevel.debug }) String
Returns a description of the tree rooted at this node. If the prefix argument is provided, then every line in the output will be prefixed by that string.
toStringShallow({String joiner: '; ', DiagnosticLevel minLevel: DiagnosticLevel.debug }) String
Returns a one-line detailed description of the render object. This description is often somewhat long. [...]
toStringShort() String
Returns a human understandable name.
visitChildren(RenderObjectVisitor visitor) → void
Calls visitor for each immediate child of this render object. [...]
visitChildrenForSemantics(RenderObjectVisitor visitor) → void
Called when collecting the semantics of this node. [...]


operator ==(other) bool
The equality operator. [...]