Open samreid opened 1 year ago
It definitely seems like an option where things shouldn't take up "no" bounds... "infinite" bounds doesn't really work too well either. To me it makes sense to be required.
Here's a patch that attempts to make it required:
There are 15 or so type errors though, with several sim-specific details to work through. So this could take 2 hours or so, and require assistance for sim devs.
I wrote on Slack #dev-public:
Currently canvasBounds is typed as optional, but failing to provide it means we end up catching bugs in QA instead of during type checking. I opened this issue to investigate https://github.com/phetsims/scenery/issues/1521, but my subteam’s choice board is filling up and I don’t feel we have time to work on it in this iteration. But I also don’t want the issue to get forgotten, so I thought I would post it here and see if anyone else wants it.
Self-unassigning.
You can search for canvasBounds?
in the code to see the places it is optional. The 3 places are: CanvasNode.ts, Sprites.ts and WebGLNode.ts.
By optional, I mean "it should be required for canvasBounds to work", sorry. But optional as an option, since you can set it with a link, etc., since we don't have the ability to set canvasBoundsProperty
with a DerivedProperty right now. We might also want to update it and NOT set it initially.
Presumably we should add an assertion that it needs canvasBounds whenever it's rendered.
In https://github.com/phetsims/greenhouse-effect/issues/255#issuecomment-1382591012, we found that photons did not render in the screenshots because
canvasBounds
was not being passed through. There are 3 places where canvasBounds is in the options, but it is optional each time. Should it be required?