wgpu image pipeline crash on window resize — possible `return` vs `continue` issue in image State::prepare

[f-o-o-g-s]

Is your issue REALLY a bug?

• My issue is indeed a bug!
• I am not crazy! I will not fill out this form just to ask a question or request a feature. Pinky promise.

Is there an existing issue for this?

• I have searched the existing issues.

Is this issue related to iced?

• My hardware is compatible and my graphics drivers are up-to-date.

What happened?

I'm getting a crash when resizing my app window. It happens when images get scaled below 1px during the resize.

Looking at wgpu/src/image/mod.rs in State::prepare, the issue appears to be the two return statements (one for raster on line 238, one for vector on line 288) that fire when an image's bounds are < 1px:

if bounds.width < 1.0 || bounds.height < 1.0 {
    return;
}

These were added in 0fe99b19 and 1463ec84 as part of the pixel snapping fixes. return here exits the entire prepare function instead of just skipping that one image — which means the final layer.push(), layer.prepare(), and the .clear() calls at the bottom don't run. That leaves stale instances in the vec and causes the buffer to be undersized on the next frame.

Changing both to continue fixes the crash:

 if bounds.width < 1.0 || bounds.height < 1.0 {
-    return;
+    continue;
 }

What is the expected behavior?

The window should resize without crashing. Sub-pixel images should be skipped gracefully.

Version

master

Operating System

Linux

Do you have any log output?

wgpu error: Validation Error

Caused by:
  In a CommandEncoder, label = 'iced_wgpu encoder'
    In a draw command, kind: Draw
      Instance 49 extends beyond limit 48 imposed by the buffer in slot 0. Did you bind the correct `Instance` step-rate vertex buffer?

[f-o-o-g-s]

i wanted to follow up on my earlier comment because i think i was wrong. i initially thought the crash was caused by a layout mistake on my end (putting fixed-size images inside flex containers) but after more testing i was still able to reproduce it even after fixing all of those issues in my code.

it looks like it is the same underlying bug described in this issue. fixing my layout code did make it a lot harder to trigger, probably because fewer elements were shrinking to sub-pixel sizes during a resize, but it did not fully stop the crash from happening.

sorry for the confusion in my earlier comment.