-
Notifications
You must be signed in to change notification settings - Fork 13
Description
I've been looking into using anyrender in Servo. Here are some problems I discovered (ordered by importance):
Panicking
Anyrender backends panic instead of returning errors. This should be easy but breaking change (should we use generic Box in anyrender traits?).
Example:
| .expect("No compatible device found"); |
Surfaces (rendering rendered scenes)
For canvas we need to efficiently use already rendered image in new rendering (as backdrop). In current servo code we call this "surface". This "render surface" must also be used by other renderers (ImageRenderer and WindowRenderer should depend on it). In vello classic this "render surface" is texture that has result of compute shader (so output texture); ImageRender would then render to "render surface" and then copy data to buffer and map it to CPU, while WindowRender would blit "render surface" to actual presentation texture (swapchain).
This is generalization of #7 with clear use case.
Here is quick sketch how this could look in anyrender:
pub trait SurfaceRenderer {
type ScenePainter<'a>: PaintScene
where
Self: 'a;
/// Native image type, that can be more efficiently passed back to the renderer.
/// This is mostly useful for cases when you want to render image of previous render.
///
/// This is usually GPU Texture
type Surface;
fn render_to_surface(&self) -> Self::Surface;
fn draw_surface(&self, scene: &mut Self::ScenePainter<'_>, surface: Self::Surface);
}alternatively maybe anyrender could support keeping/preserving backdrop, because I suspect this could be done more efficiently on some beckends (there was some talk about this in vello somewhere).
Clipping
We would need to sort out clipping story. The most problematic thing is that we cannot do just clipping or do layers without clipping (at lest not without knowing viewport size we can bypass this by giving it big rectangle). Vello already has push_clip_layer and anyrender should too. We should make push_layer take Option<impl Shape> for clip (as vello_cpu does).
We would also benefit from something like linebender/vello#1203, but that's another story.
Non-isolated blending
For canvas we would benefit from non-isolated blending, the api would be Option<BlendMode> on each draw command.
This is WIP in vello_cpu: linebender/vello#1159 and skia also provides this per paint/draw command so we would benefit there. On others we would need to simulate this by wrapping draw command with temporary layer.