Auto-Resize #584
Auto-Resize #584
Conversation
There was a problem hiding this comment.
Right. All of this looks really good except for two things:
- Have we lost the delay on resize?
Maybe you're saying we don't need it anymore? But the point of the debounce code was to not resize on every little twitch of the dimensions, because you end up with ugly graphical tearing or squash n' stretch rendering. It also means the WebGL context is being adjusted a lot which is bad news for performance. We've lost the debounce code (yay!) but not replaced it with an alternative, it seems?
- Do we really need the
ApplicationResizeevent?
The real difference between ApplicationResize and ViewportResize is that the former reports any change in the size of the container whenever that happens, and ViewportResize reports any change in the size of the useable rendering area after the rendering context has been reinitialised.
I expect only ViewportResize is interesting to the majority users. The only use I can think of for ApplicationResize, is manually re-implementing the debounce function as mentioned in point (1).
| @@ -2,32 +2,8 @@ package indigoplugin.templates | |||
|
|
|||
| object SupportScriptTemplate { | |||
|
|
|||
| def template(autoSize: Boolean): String = | |||
| def template(): String = | |||
| s""" | |||
There was a problem hiding this comment.
I am happy to see this go! ❤️
| def autoResize: GameConfig = | ||
| withResizePolicy(ResizePolicy.Resize) | ||
| def autoResizePreserveAspect: GameConfig = | ||
| withResizePolicy(ResizePolicy.ResizePreserveAspect) |
indigo/indigo/src/main/scala/indigo/platform/events/GlobalEventStream.scala
Outdated
Show resolved
Hide resolved
Yes.. but also no. The delay now is down to resource. If JS has enough resource to deal with a resize event then it will, rather than stressing the browser. If it doesn't then it won't and it will wait until it does. This means we're no longer waiting a set time to decide we've waited long enough, the browser is deciding based on the machine capabilities.
Possibly not. If you don't think it's useful, I'm happy to remove it :) |
hobnob
force-pushed
the
features/autoResize
branch
from
da707cc
to
54a266f
Compare
There was a problem hiding this comment.
Excellent work @hobnob - delighted to see the debounce script deprecated! I've tested it locally and it's a big improvement. 🎉
Now the canvas can resize itself we centre the canvas so that if the aspect of the window is not the same as that of the canvas then it will always appear in the correct position
hobnob
force-pushed
the
features/autoResize
branch
from
be0ff4b
to
d075e79
Compare
This PR closes #469 by removing
debouncecompletely and adding automatic resizing throughout Indigo. This is another breaking change I'm afraid, as theGameConfighas now been given a new property calledresizePolicy, which determines the way Indigo reacts to a resize. The new default behaviour is for Indigo to always resize depending on how big the container is. Whether this is sensible or not remains to be seen, but it felt sensible at the time 🙂The resize policy can be changed in the
GameConfigusing either:withResizePolicy(resizePolicy),noResize,autoResize, orautoResizePreserveAspect.This is all implemented using the Resize Observer, on the parent container. This is the recomended way of observing size changes, and will fire whenever the containing element changes size and waits for resource to be free before it does so. Indigo will fire an
ApplicationResizeevent to let the app know it's being resized (for developer information really), and will then resize the canvas according to the policy, either not taking any action (NoResize), resizing to the entire width and height of the container (AutoResize) or resizing while maintaining the aspect ratio of the canvas element (AutoResizePreserveAspect).It's worth noting that any CSS that overrides the
widthandheightattributes of the canvas will interfere with the resizing policy and may produce unexpected results.