Reliably clear to default clear color#137
Reliably clear to default clear color#137tychedelia wants to merge 4 commits intoprocessing:mainfrom
Conversation
| /// This is necessary on some platforms (notably macOS) to avoid issues with the first few frames of | ||
| /// rendering being corrupted or not appearing at all. | ||
| /// | ||
| // TODO: why is metal particularly affected by this? can we remove this? |
There was a problem hiding this comment.
is there a bevy issue we can track related to this? if so can we ref the issue here?
There was a problem hiding this comment.
No, although I was able to create a reproduction in Bevy. I should try to create a reproduction in raw wgpu to confirm. It's a bit tricky because our "sketch" requirements (i.e. load semantics on the color attachment plus first frame transient raster) are very unusual for graphical applications. I tried to dig into the xcode debugger but was having trouble reproducing under instrumentation.
There was a problem hiding this comment.
It's also possible this is just a M1/M2 thing...
|
@SableRaf would you be able to test this on your machine by any chance? |
|
I'm testing on Note: when doing the same test on the main branch, the sketch runs fine. |
|
Okay, I just pushed a few small changes that should remove that error and make this work reliably. |
Fixes #134
Metal on wgpu seems to reliably have issues with persisting the first render pass on a texture. We have a workaround here to ensure that we do some work on the texture before our "real" frame 0, which is typically the user's setup function.