vello_cpu: Make RenderContext resizable#1705
Conversation
|
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? |
|
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.
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? |
|
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. |
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