Cache Vello render output as stitchable textures#3722
Conversation
Performance Benchmark Results
|
Performance Benchmark Results
|
c8cf08b to
01b4c1f
Compare
Performance Benchmark Results
|
01b4c1f to
f79c30c
Compare
b8a716a to
6950a74
Compare
|
We don't store tiles, so I think the title is technically wrong / misleading |
1b42423 to
0af8665
Compare
0af8665 to
722d379
Compare
865572b to
74332a5
Compare
timon-schelling
left a comment
There was a problem hiding this comment.
Generally LGTM, didn't check the cache as thoroughly. Can do that if you want but the approach is good.
editor/src/messages/dialog/preferences_dialog/preferences_dialog_message_handler.rs
Outdated
Show resolved
Hide resolved
|
|
||
| executor.context.queue.submit([encoder.finish()]); | ||
| surface_texture.present(); | ||
| // image_texture.texture.destroy(); |
There was a problem hiding this comment.
| // image_texture.texture.destroy(); |
| let queue = &exec.context.queue; | ||
|
|
||
| // TODO: Use texture pool to reuse existing unused textures instead of allocating fresh ones every time | ||
| let output_texture = device.create_texture(&wgpu::TextureDescriptor { |
There was a problem hiding this comment.
Could we use target texture here? Only needs to be recreated if viewport size changes?
There was a problem hiding this comment.
Not sure what you mean by this. We should not overwrite a texture that is in use by someone else, in which case we would return a new texture until the old one becomes unused again, which is what the texture pool would be
d9c71ba to
6147918
Compare
Keavon
left a comment
There was a problem hiding this comment.
Good to go from a UI perspective and to the extent of the regression testing I've done. Please merge when you feel it's ready, ideally after marking Timon's comments as resolved after considering them.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a tile-based render caching system for the Vello renderer, significantly improving performance during viewport panning by only re-rendering necessary parts of the document. The implementation includes a new render_cache module in graphene-std, updates to the editor preferences to allow user control over Vello usage and tile resolution, and optimizations in the message dispatching logic to batch frame-related updates. The caching logic correctly handles scale changes and animation/pointer-based invalidation. Key feedback points include addressing potential panics from unwrap() calls in the render pipeline, optimizing texture allocation by implementing a pool, and cleaning up commented-out code in the runtime.
* WIP render caching * Hook up render cache to render pipeline * Fixed offsets * Initial cleanup * Integrate cache with context invalidation * Cleanup * Improve rounding and reduce tile size to fix vello not rendering * Include pointer position in cache key * Avoid unwraps and zero sized textures * Destroy textures after blitting to surface * Fix context dependencies * Exclude footprint from render params * Batch animation frame messages * Add vello max render size to preference dialogue * Remove unused import * Reorder vello preference * Clean up preferences dialog * Apply review suggestions * Cap max render region size --------- Co-authored-by: Keavon Chambers <keavon@keavon.com>
|
Regression found: #3807 |
Cache render output as texture and only rerender necessary parts while panning
Closes: #3509, part of #1607.