Improved readback data handling #1734
Conversation
Do smaller readback chunks
| /// While readback buffer starts are guaranteed to be aligned correctly, there might need to be extra padding needed between texture copies. | ||
| /// This method will add the required padding between the texture copies if necessary. | ||
| /// Panics if the buffer is too small. | ||
| pub fn read_multiple_texture2d( |
There was a problem hiding this comment.
this became multiple for the sole purpose of handling depth textures later on. Struggled a lot with expressing the "I want several things to be done at once" and opted for the less user friendly way since I only have one usecase in mind right now and I think I know what I'm doing (wish me luck) ;)
|
I'll happily take that one first thing tomorrow morning |
| } | ||
|
|
||
| { | ||
| let range = chunk.ranges_in_use.swap_remove(range_index); |
There was a problem hiding this comment.
Wait, how is this legal? we're invalidating the iterator?! I assume I'm missing the obvious and need to go back to bed...
There was a problem hiding this comment.
it's legal because there's a return after it. When writing this I was hoping so badly that it gets that and then it did \o/
There was a problem hiding this comment.
but... there is no return? the only return that follows is conditional?!
There was a problem hiding this comment.
no, the return here is unconditional. It is after a conditional, but the return is not part of it
There was a problem hiding this comment.
or rather, the return is still conditional but it is in the same condition as the line you commented on. I.e. both swap_remove happen only when the loop is definitely exited
Makes it much easier to handle readback data. There's a bunch of paradigm shifts in how we do administrate them now:
ScreenshotProcessor(new! shifting further towards a class-per-draw-pass; this is still an ongoing evolution!) orPickingLayerProcessorwrap your userdata and provide everything you need to know about for their readback dataTesting:
Checklist