Skip to content

vello_cpu: Make RenderContext resizable#1705

Open
LaurenzV wants to merge 2 commits into
laurenz/vello_cpu_rewritefrom
laurenz/resize_ctx
Open

vello_cpu: Make RenderContext resizable#1705
LaurenzV wants to merge 2 commits into
laurenz/vello_cpu_rewritefrom
laurenz/resize_ctx

Conversation

@LaurenzV

Copy link
Copy Markdown
Collaborator

This is based on top of #1701. Now we can make the render context fully resizable, which means that it can be reused even if the window size changes!

resize.mp4

@LaurenzV LaurenzV requested a review from grebmeg June 11, 2026 07:27
@nicoburns

Copy link
Copy Markdown
Contributor

Sounds useful! I would interested in what the cost of a resize is with this API vs. the cost of having a RenderContext that's too big, and whether there would be value in quantizing resizes and rendering to a subregion of the size (e.g. like macOS's IoSurface that only resizes in 32 pixel increments). Could also apply to glyph rendering where you might a slightly oversized RenderContext that can render all the glyphs rather than resizing each time?

@LaurenzV

Copy link
Copy Markdown
Collaborator Author

To be honest, there barely is going to be any difference in terms of cost. If just keeping a larger render context works for you, that's fine as well. However, it somehow bothers me being unable to adjust the render context size to the one of the pixmap. 😄 Of course, there is the advantage that anything that exceeds the width/height will automatically be culled away, which won't be the case if you don't resize. However, if you already know ahead of time that the bounding box of whatever you about to draw won't exceed the pixmap dimension, then it doesn't really change much.

and whether there would be value in quantizing resizes and rendering to a subregion of the size (e.g. like macOS's IoSurface that only resizes in 32 pixel increments).

I'm not sure I get what you are asking here, do you mean whether you will get any performance benefit by resizing in such increments?

@nicoburns

Copy link
Copy Markdown
Contributor

I'm not sure I get what you are asking here, do you mean whether you will get any performance benefit by resizing in such increments?

Yeah, I guess it's "how expensive is resizing", and therefore "how much can be saved by not resizing or resizing less often". For something like glyph rasterization, I imagine it may end up being a not-insignificant amount of the total render time. And for latency when resizing windows it might matter too?

@LaurenzV

Copy link
Copy Markdown
Collaborator Author

I mean resizing is basically just resizing a some vectors (as can be seen in the PR), so it should basically be free in the grand scheme of things. I haven't measured it but even for small targets I don't think it's gonna matter at all.

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