What to do with onGameResize ?

[st-pasha]

Method onGameResize() has been in Flame for a very long time, and it has two purposes:

1. It is called after prepare() but before onLoad() when a component is added to the game tree.
2. It is called for every component in the game tree when the size of the game widget changes.

The reasons why this method behaves this way are, AFAIK, also twofold:

1. In the onLoad() we want to know the size of the game canvas, so that we can adjust the size or position of the component, or load appropriate assets that depend on size.
2. Those components that are sized/position depending on the size of the screen will want to update their position and size if the size of the screen changes.

I would argue that these reasons no longer hold.

First, knowing the size of the game canvas in onLoad is now easy: it's simply gameRef.size. It used to be the case that onLoad was called before the component was inserted into the game tree, and thus neither gameRef nor parent weren't available. But #906 has removed that particular hurdle, so a component that needs to know the size of the game can now find it easily.

Second reason is more interesting. I think if we look at the examples here, we'll see that the most common use case is the "HUD" components, for example a score display in a corner, health/energy bars in another corner, a joystick, etc. Notably, all such HUD components are conceptually tied to the viewport, not to the screen. Of course, it is common to have the viewport be as large as the screen -- but it need not be always so. Then we'd want onGameResize to be called for these components when the viewport size changes, which may happen independently of the game canvas size change.

Another example when components would want to listen to onGameResize is when the game implements a custom layout and every component in the game is positioned according to the screen's real size. This use case is more rare, of course, but I think it can be safely categorized as equivalent to the previous one, if we imagine that everything in the game is part of the HUD.

So, my argument for the second point is that having an event that fires when game canvas is resized is not particularly useful. What is probably more useful is to have an event tied to the viewport resize (onViewportResize?). Or, more generally, there could be an event tied to resize of any component, allowing the children of that component to respond appropriately (onParentResize?).

The thing is, though, it's already possible to have a callback tied to resize of any PositionComponent: just register a listener to its .size property. So maybe we could just go with this approach instead, only make it more universally applicable?

[spydon]

I'm leaning towards your last suggestion, but it should not only work for PositionComponent, it needs to work for Game too. What type of listeners are we talking about here, the ones in NotifyingVector2 I presume? Because for some reason we return a Vector2 and not the NotifyingVector2 for size in PositionComponent (and Game does not utilize NotifyingVector2). We also need good documentation of how to do this if we remove the on*Resize.

[erickzanardo]

IMO, we could add an onViewPortChange, but I would keep onGameResize, they may be edge cases but still may be something that people may need, especially if they don't use camera or viewport at all.

About listeners, I am not sure, we would need to keep track of them for cleaning subscriptions when the components are remove, so seems to be a lot of work for something that we already have working fine.

[wolfenrain]

Yea the camera and viewport are defaults, so people who use the lower APis will lose some ability there unless we provide a different way of listening to resizing.

The last suggestion shows most potential but as @spydon mentioned it should also work for Game then. That would allow people to also have proper size listeners without having to depend on a camera/viewport.