re_renderer: detect badly sized texture buffers before handing to wgpu

[emilk]

What

• Closes Viewer blindly trusts tensor dimensions and crashes if buffer is too small #3927

wgpu does no validation right away, but defer it to a background thread, leading to lack of good error messages, and sometimes panics.

So we need to do the best we can up-front!

I tested this with:

--- a/docs/code-examples/image_simple.cpp
+++ b/docs/code-examples/image_simple.cpp
@@ -21,5 +21,5 @@ int main() {
         }
     }
 
-    rec.log("image", rerun::Image({HEIGHT, WIDTH, 3}, std::move(data)));
+    rec.log("image", rerun::Image({HEIGHT + 100, WIDTH, 3}, std::move(data)));
 }

Result:

[2023-10-25T13:10:56Z ERROR re_space_view_spatial::parts::images] Failed to create texture for "image": Wrong number of bytes in the texture data buffer - expected 300x300x4=360000, got 240000

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[Wumpf]

wgpu does no validation right away, but defer it to a background thread,

that's incorrect. There's nothing threaded about this, there's excessive validation pretty much immediately. It's just that we don't handle the wgpu error callback right now and even if we would it would be too late (especially particular on actual WebGPU where this may indeed be delayed).

Change lgtm but Texture2DBufferInfo is kinda made for this size check.

I'm a bit surprised we're not adding any other validation much earlier in the pipeline as well, since clearly we got malformed data in. But the resulting error message looks good enough indeed, so this will do!

[Wumpf]

why don't we use our Texture2DBufferInfo class here instead and check for its buffer_size_unpadded field?

[emilk]

Why not? Because nothing in this function uses Texture2DBufferInfo, so it didn't occur to me. Also it requires me to write more code and understand what buffer_size_unpadded is in relation to the input data.

Counter-question: why use Texture2DBufferInfo and buffer_size_unpadded here? Would it make the code shorter? Or more correct?

[Wumpf]

it sure would make it more correct. As is the code will fail again in the future when somebody comes with a compressed format in which case we'll don't do any check at all then

[Wumpf]

Because nothing in this function uses Texture2DBufferInfo, so it didn't occur to me.

it probably should though, the function predates this utility :)

As for understanding buffer_size_unpadded: The code sadly already requires you to understand this since we deal with two different kind of widths in here, the padded and the unpadded one.
Looks like we offloaded that to wgpu by now here. The variable names are just reminiscent of when we didn't

[Wumpf]

I mean it's not a big issue at all, I approved the PR didn't I? 😄

[Wumpf]

also wondering if the viewer should try to truncate the image 🤔