### Topic When debugging https://github.com/processing/p5.js/issues/7071 with @Vishal2002, we noticed a bug in my original bug report's code: I was creating a framebuffer camera in `setup` with `createCamera`, and it was accidentally being set as the main canvas's camera. This was happening because the default behaviour of any `createCamera()` call is not only to return a new camera, but also to basically call `setCamera()` on it too. If you don't want that, you have to manually surround it with `push`/`pop` or an equivalent. Some thoughts: 1. If you have just one camera, this is probably fine 2. If you switch between multiple cameras, it starts to get a little weird because the last one you create is the default one, unless you do something to prevent that 3. You basically never want this behaviour for framebuffer cameras, since they should only be applied between a framebuffer's `begin`/`end` There are a few ways we could try to resolve this, from lightest to heaviest touch: - **Call out the weird cases in the docs.** This is probably not that effective since it's easy to miss even when you know the behaviour. - **Make framebuffer cameras not auto-apply themselves.** This would resolve point 3 without really being a breaking change, because it would have caused buggy behaviour before if you were creating a framebuffer camera outside of `push`/`pop`. It introduces a bit of inconsistency, but the way you use cameras in framebuffers is already a bit inconsistent because you have to apply a camera within each `begin`/`end` due to it not saving state between draws. - **Make all cameras not auto-apply themselves.** This would perhaps be the most consistent with other creation methods in p5 (they don't usually have side effects), but would also be a breaking change, so this would maybe have to be for 2.0.