Skip to content

Pass Backdrop into render* - #95

Draft
sagudev wants to merge 1 commit into
DioxusLabs:mainfrom
sagudev:backdrop
Draft

sagudev wants to merge 1 commit into
DioxusLabs:mainfrom
sagudev:backdrop

Conversation

@sagudev

@sagudev sagudev commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

Based on the idea from #29 (comment)

Most backends already had some form of this logic so I think it just makes sense. Only vello and vello_hybrid needed additional work for preserve, skia and vello_cpu implements it naturally.

Draft because it needs tests? As far as I can tell there is no way to do asser expect image tests.

Signed-off-by: sagudev <16504129+sagudev@users.noreply.github.com>
@nicoburns

Copy link
Copy Markdown
Member

I'm broadly onboard with this. It looks like there is work in vello_hybrid that might enable this there too? (linebender/vello#1869 ?)

Some questions:

  • Do you think it's better to emulate when not supported (or simply fallback to a clear mode)?
  • Presumably this will be rendering to Texture rather than an output surface (display)? Do you think we need a new TextureRenderer abstraction or similar? Or to adapt WindowRenderer into a more general SurfaceRenderer?

If we do a general abstraction I'd been keen to avoid an associated type (because dyn compatibility).

@sagudev

sagudev commented Sep 3, 2026

Copy link
Copy Markdown
Contributor Author

I'm broadly onboard with this. It looks like there is work in vello_hybrid that might enable this there too? (linebender/vello#1869 ?)

It sure looks like it. IIRC there was also talk about this in vello. And maybe I will help it make it happen in the future.

* Do you think it's better to emulate when not supported (or simply fallback to a clear mode)?

I think it's better to emulate to keep stuff consistent and that is what current PR does. My hope is that in the future we will get this everywhere, so no emulation will be needed anymore.

* Presumably this will be rendering to Texture rather than an output surface (display)? Do you think we need a new `TextureRenderer` abstraction or similar? Or to adapt `WindowRenderer` into a more general `SurfaceRenderer`?

If we do a general abstraction I'd been keen to avoid an associated type (because dyn compatibility).

Currently we have "localized" Preserve which means that we preserve content of output texture (even if blitted from intermediate texture), which I now realize might not be that useful if window uses swapchain (we get new/cleared texture for each frame), but one could use that to preserve content within frame (although one should probably not do this) or by manually blitting. We could make it into "Global" preserve by using intermediate texture, but then we get the question of how to clear it (let it to the user?).

I think TextureRenderer would be proper abstraction that could be then used by both Image and Window renderer (less duplication!). Image renderer would simply "download" data from texture into cpu buffer (nop in case of cpu renderers as their textures are cpu buffers) and we can also reuse download logic in case to keep dyn Texture (if wrong texture type is provided we do conversion - download/upload or panic).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants