z-order painting

[cmyr]

Certain paint operations need to be able to specify their z-index; that is, that they should be painted above or below other content, even if it is lower in the tree.

Our strategy for this, for now, is to only allow over-painting; that is, you can specify that you should be drawn after other content, but not before. This is a limitation, but it covers the majority of cases, and it dramatically simplifies the API.

design:

We will add a new method to paint_ctx, that looks something like this:

impl PaintCtx {
    fn paint_with_z_index(&mut self, z_idx: u32, paint_func: impl FnOnce(&mut PaintCtx) + 'static) {
        // take this closure, the z_idx, the current transform and the current `Region` and push it to a vec
    }
}

During the normal paint traversal, normal painting operations are performed in the normal (traversal) order; and paint operations that are made through this function are accumulated. After the traversal we sort any stashed paint closures by their z-index, and then execute them in order.

I think this should basically just work, and it's a very self-contained addition. The only hand-wavy part, right now, is ensuring that we set the transform and region of the PaintCtx correctly for each closure, based on the state at the widget that submitted it; but this should be something that can be handled automatically by the WidgetPod, unless I'm missing some detail.

[scholtzan]

I've been playing around and trying to get this work. One thing I haven't been able to get to work is applying transformations correctly. Is there an elegant way of getting currently applied transformations for a PaintCtx? I saw current_transform in piet which seems to return the transformations, however this is not available for PaintCtx at the moment.

[raphlinus]

Yeah, I can see transformations being a challenge here. I believe current_transform is an implementation detail for only some piet back-ends. One possibility is to export it publicly (which might require more mechanism to track it in piet back-ends that don't already use it). Another possibility is to put some stuff in at the druid level to wrap raw piet transformation.

It's unclear to me whether z-order painted items should be subject to clipping or not. If so, we'll have to track clip regions as well. Thinking forward, I'm also concerned about routing of mouse events - these currently happen by layout bounds, and it seems to me that if there's a combo box, those should be routed more or less as if there's a popup window.

[cmyr]

So I think we'll either need to make current_transform() an explicit part of the piet API, or else we will want to put the various transform methods on PaintCtx, and keep track of them there. It's likely easier to add this in piet, but I haven't actually dug in so I'm not entirely sure.

I think that the mouse event stuff isn't directly related to z-order, it's a detail of how we will want to do combo boxes?

[cmyr]

closed by #504