I don't think I agree with this decision. The performance argument isn't convincing at all to me without data, and this will make quick experiments and examples less useful since you won't be able to see black lines that are drawn.

Not being able to see black lines isn't a convincing argument to me, since white-on-black is easier to see than black-on-dark-grey or white-on-dark-grey.

On the performance side, check https://gpuopen.com/learn/rdna-performance-guide/#clears; while I don't have performance metrics, I was directed here.

While I agree with this in principal, I think we should delay it until we add procedural skyboxes. Probably sometime in 0.13 assuming I don't run into major issues.

The thing is, if someone wanted a non-black background, chances are they set it manually anyway. The default color is almost certainly not used in production ever except by accident. I don't think procedural skyboxes are needed for a simple change that affects almost nobody; if someone wants to use a non-black clear color, there's nothing stopping them from doing so. All this does is change the default.

I also agree with this in principal and I think @JMS55 point about skyboxes is a good one.

I tend to think that hidden costs are much more difficult to be aware of / discover than things that just don't work.

When lots of things will use some kind of skybox or background of some form which will replace all the clear colour, it would be difficult to be aware of the lost performance from slow-path clearing of textures and from what I recall from @HackerFoo 's work on the Noumenal mobile app, things like clearing buffers has significant impact on mobile in particular. AMD/NVIDIA also recommend using fast paths for clearing/initialising textures if possible.

On the other hand, not being able to see black lines on a black background is immediate and clear friction that is actionable.

I'm still somewhat failing to see the problem with black lines on a black background; if the background is obviously black, why isn't it trivial to make the lines white?

Edit: Oh right, that's your point: it is trivial to fix, but clear color is less obvious -- oh, that makes more sense, and I completely agree.

Yep :) Note that this will have an impact on more complex rendering examples too: things like the examples that demonstrate the effects of lighting and PBR materials will look quite different on a black rather than neutral-gray background!

I'm fine to defer to the tastes of the rendering experts here, but we should verify that all of the visual examples still look fine as part of this PR and manually set the clear color (or change the line etc. color) as needed.

Are there automated tests to check against an existing screenshot?

I think @mockersf was working on something like that here: #9220

Triage: has merge conflicts
@rdrpenguin04 do you want to update this PR or should I tag it S-Needs-Adoption? :)

I can update the PR, sure; I just got on summer break anyway

Edit: We're up to date now.

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-9540

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

(yes, this does need M-Deliberate-Rendering-Change)

@mate-h @ecoskey, how do y'all feel about this as a default now that we have a skybox impl?

@rparrett, how do you feel about the impact of this on our examples? Should we add boilerplate to every example, reject this PR, or do something hacky to get the best of both worlds?

I think I'm personally in the "reject this PR, write a book chapter and template for perf optimzation" but I do agree that this is kind of a silly situation.

@rparrett, how do you feel about the impact of this on our examples? Should we add boilerplate to every example, reject this PR, or do something hacky to get the best of both worlds?

IMO, given the assumption that this is an large and important optimization, I'd probably just take the minor aesthetic hit. Not the end of the world, but many examples would need adjustments as we did in #10339. Cart's opinion would be more valuable here, because I can't quantify either the branding value or performance impact.

If this is a minor optimization in the grand scheme of things, or if there's no motivation to make a determination to that end, then I like the plan to close and educate. Maybe we can warn or override if there's a skybox or something?

And in any case, we should probably give some info on fast clears the clear color related docs:
https://docs.rs/bevy/latest/bevy/prelude/struct.ClearColor.html
https://docs.rs/bevy/latest/bevy/prelude/enum.ClearColorConfig.html

One option could be to create a "default clear color" resource that the examples (with the exception of ones involving a changed background) all insert to be the bevy-default-grey, so the examples still use the same grey and fit the Bevy branding.

The motivation for making this change at all is that AMD's own documentation seems to imply that a non-fast clear is a major performance drop. I'm a bit surprised that it's supposedly this big of an impact myself.

I think Alice's mention of the word "boilerplate" scared me off, but you are right, app.insert_resource(ClearColor::BEVY_GRAY) (or whatever) really isn't a huge burden.

Another option could be a feature flag that sets the clear color to bevy-gray, and the examples use that.

Or what you said about detecting a skybox and automatically disabling the clear color. There are a lot of options; I truly did not expect a two-line change to be this controversial :)

@mate-h @ecoskey, how do y'all feel about this as a default now that we have a skybox impl?

I'm fine with the change personally, especially since setting a per-app default with the ClearColor resource is so easy, but I don't feel too strongly. I'm a little surprised the gray clear color hasn't caused problems for atmospherics actually, considering it composites on top of the existing background 🤔. I guess it'd also be technically "more pbr" to have a black background unless there's an env map enabled, but we probably shouldn't strongly link those.

app.insert_resource(ClearColor::BEVY_GRAY)

This seems like a fine solution to me, but I'm sure @cart will have feelings. I feel like we should do that as part of this PR, to avoid creating a ton of noise for the screenshots and collect the changes into a single atomic item.

Pretty soon, I think we should be moving many of our examples away from a clear color background, and towards a slightly more realistic procedural skybox or something anyways.