There should be an option to resize the canvas along with the browser window

[jgarvin]

Describe the bug
The demo is always the same size and is always a small part of the screen. Nothing happens when you resize the browser window.

To Reproduce
Copy the resize demo to main.rs, add quicksilver dep, then run cargo web start --release --auto-reload --features quicksilver/stdweb and visit in Chrome.

Environment and versions (please complete the following information):

• Environment: Ubuntu 19.10, Chrome Version 81.0.4044.138 (Official Build) (64-bit)
• Rust compiler version: rustc 1.44.0 (49cae5576 2020-06-01)
• Quicksilver verison: quicksilver = "0.4.0-alpha0.5"

[ryanisaacg]

This is the expected behavior. On the web, resize events are fired only when entering or exiting full-screen mode.

[lenscas]

This is the expected behavior. On the web, resize events are fired only when entering or exiting full-screen mode.

In that case, what happens if size of the canvas changes (due to CSS) ? Would it just be the same as if you wouldn't handle the resize events on native?

[jgarvin]

Could the default size be changed to fill the window? Visiting your game html and having it only take up ~1/4th of the screen (why that size? it must be specified somewhere?) doesn't seem like a good out-of-the-box experience. If I use macroquad for example, everything always resizes to fit in the visible space. I imagine that is closer to the experience most people are looking for, but admittedly I haven't done any kind of poll.

[lenscas]

You can set the size of the canvas through the settings https://github.com/ryanisaacg/quicksilver/blob/master/examples/10_resize.rs#L15

If you ask me how it should work then:
If you don't touch the default CSS and/or html it should behave as it currently does.
However, you can change the CSS so the canvas can become bigger/smaller depending on the size of the browser which would trigger the resize events.

[jgarvin]

Possibly my use case is different from other users -- the reason I'm using something like quicksilver is I don't have any web development background (most of my experience is C++ backend), and frameworks like quicksilver seem like a way to make a game that can run on a single webpage by itself, without having to learn all the html/javascript/css details. A lot of the wasm guides seem to assume your goal is to embed some wasm thing in the middle of a regular HTML site and interface with legacy javascript libraries, but I just want to visit mygame.html and have it be the whole document. For people like me it would be nice to not have to think about CSS, but maybe that's unavoidable?

[ryanisaacg]

@lenscas

In that case, what happens if size of the canvas changes (due to CSS) ? Would it just be the same as if you wouldn't handle the resize events on native?

The canvas changing size due to CSS will not fire an event. I don't believe that listening for a CSS change of the size to fire an event is well-supported by the web platform, but I could be wrong.

@jgarvin

Could the default size be changed to fill the window?

Personally I think you're better off having a fixed-size canvas, or going into fullscreen mode. As far as I'm aware, keeping the canvas to the same size as the browser window involves a few hacks.

(why that size? it must be specified somewhere?)

Yup, that's the default value for Settings::size. If you pass in a different value, you'll get a different canvas size.

[willmcpherson2]

My solution to this is some rather unfortunate glue code. Essentially just an implementation of this stackoverflow answer. I'm not sure how quicksilver can make this easier, but I am interested in getting rid of this code by implementing something upstream 😛

[lenscas]

I read the code and the comment. About
Even though my script runs last, I still have to wait for the canvas to be created.
My guess is that stdweb is waiting for the document to be loaded, which normally is a good thing. Try to wait on that yourself as well rather than the timeout thing? There should be an event for that that you can subscribe to.

Also, I would rather not provide any HTML/CSS/JS and just use the cargo-web defaults
Sooner or later you will have to provide your own html file unless you really don't plan any styling. Don't beat yourself up on it.

as for a way to improve the code by implementing something upstream: I guess having quicksilver expose a function to JS that fires the resize event would improve it? Then people can resize it based on whatever.

However, I think that exposing a function like that should be done by winit, rather than quicksilver (winit being the windowing library quicksilver uses)

[willmcpherson2]

@lenscas
Thanks, I’ll try to do something like that.
And I definitely think quicksilver’s resize event should be somehow connected to the JavaScript window resize event. At the moment quicksilver’s resize event seems to do nothing on the web?
I’m not sure who’s generating the web files but this can all be done from there, no? Unfortunately the generated .js is quite hard to read and even has some name mangling 😦

[lenscas]

And I definitely think quicksilver’s resize event should be somehow connected to the JavaScript window resize event

I don't think so, or at the very least that behavior should be configurable. The most flexible and easiest to implement would be to expose a function that sets the new height/width and generates the resize event.

At the moment quicksilver’s resize event seems to do nothing on the web?

Correct, as stated by @ryanisaacg that is expected behavior.

I’m not sure who’s generating the web files but this can all be done from there, no?

Either wasm-bindgen or cargo-web generate the files depending on what you use. Not sure wat "this" in that sentence refers to?
If you are talking about exposing a function to trigger the resize event, yes both should have ways to expose a function like that but right now neither winit nor quicksilver tell cargo-web or wasm-bindgen to expose such a function. (At least, winit doesn't do this to my knowledge)

Unfortunately the generated .js is quite hard to read and even has some name mangling
I agree that that makes debugging not always as nice as it could be when incorporating JS into quicksilver