Paint bounds #401
Labels
architecture
changes the architecture, usually breaking
Comments
Closed
cmyr
added a commit
that referenced
this issue
Feb 6, 2020
This introduces the idea of a 'paint rect', which is the region that a widget wishes to paint inside. In the general case this is equivalent to the widget's layout rect; the exceptions are cases where widgets explicitly wish to paint outside of their bounds. the paint region is specified as Insets relative to the layout rect. Widgets that need an explicit paint region specify that region when handling the Widget::layout method. closes #401
cmyr
added a commit
that referenced
this issue
Feb 6, 2020
This introduces the idea of a 'paint rect', which is the region that a widget wishes to paint inside. In the general case this is equivalent to the widget's layout rect; the exceptions are cases where widgets explicitly wish to paint outside of their bounds. the paint region is specified as Insets relative to the layout rect. Widgets that need an explicit paint region specify that region when handling the Widget::layout method. closes #401
cmyr
added a commit
that referenced
this issue
Feb 7, 2020
This introduces the idea of a 'paint rect', which is the region that a widget wishes to paint inside. In the general case this is equivalent to the widget's layout rect; the exceptions are cases where widgets explicitly wish to paint outside of their bounds. the paint region is specified as Insets relative to the layout rect. Widgets that need an explicit paint region specify that region when handling the Widget::layout method. closes #401
cmyr
added a commit
that referenced
this issue
Feb 7, 2020
This introduces the idea of a 'paint rect', which is the region that a widget wishes to paint inside. In the general case this is equivalent to the widget's layout rect; the exceptions are cases where widgets explicitly wish to paint outside of their bounds. the paint region is specified as Insets relative to the layout rect. Widgets that need an explicit paint region specify that region when handling the Widget::layout method. closes #401
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
At the moment, there's no enforcement of where widgets can paint, so there's nothing stopping them from painting outside their layout bounds. However, container widgets might skip painting a widget when the paint region doesn't overlap the widget's layout bounds, leading to potential visible artifacts (the most likely is a widget "popping" into visibility on scrolling).
A much more systematic approach would be to track the actual paint bounds of a widget. I propose a new
set_paint_boundsmethod onLayoutCtx. If this function is not called during a layout, then the paint bounds are set to the layout bounds (thus, this function is opt-in). Further, during layout we should keep track of the union of the paint bounds of all the children, and make that available. A simple container (that does no painting of its own) will callset_paint_boundsto this value.An interesting question is whether an
updateshould also be able to update the paint bounds (without also changing the layout bounds). However, it is difficult to figure out the logic of how this should propagate up, so for simplicity it's probably best to request layout (#400), and then in the future we can be finer grained about minimizing the work when the layout bounds are not actually different.The text was updated successfully, but these errors were encountered: