How to think of windows, resizing, monitors, fullscreen mode in context of a browser.

[dmitshur]

This issue is to discuss how to think about and how to map the GLFW desktop concepts such as windows, resizing, monitors, fullscreen mode, etc., in the context of a browser. It resumes the discussion started in #8.

[dmitshur]

In #8 (comment), @Omustardo said:

The basis for all of the questions relies on what exactly is the GopherJS/HTML equivalent of the GLFW window. I'd consider it to be the canvas element alone, since that's all that we render into. It's not entirely accurate, since input handling affects the rest of the page (e.g. you can't right click in the whitespace in the tetris demo), but perhaps it's as close to a standard desktop GLFW window as can be expected. If that's not a good assumption, then the rest of this logic is going to be wrong, but it's a starting point.

I think thinking of canvas as the equivalent of a window is one approach. It's viable. But it's not the only approach. Let's first enumerate all the viable alternatives and compare them. Here's what I can think of that can map to a GLFW window:

1. The canvas element specifically.
2. The current browser window that's displaying the current page you're on.
3. A new popup window created programmatically via window.open.

Currently, goxjs/glfw implements option 2. I've thought about 1 and 2, starting with 1, and decided to move towards 2.

The observation I made was that too many window abstractions are not helpful. It's counter-productive to have a window (GLFW window as the canvas element) inside the browser window. The user can already move and resize the browser window, why would they want to move a canvas element window inside the browser window?

So I decided to go with 2 and forfeited the ability to control the window size at creation time, as well as programmatically resizing the window. Instead, the user controls window size and position by resizing and moving the browser window. This seems to work well.

If a game or app cannot use a given size, it can simply add padding around the unused area and draw in the center.

If the GLFW window is just the canvas, then it shouldn't affect other elements. If users want to do so, they can modify the js/html.

Like in the previous point, if the canvas is the glfw window, then its position is something the user should deal with through js/html. A visually pleasing default seems reasonable though. Subjectively I'd go with centered or top center. I don't do much web programming so I'm not sure if there's a technical advantage for either.

They can, but it's hard and I think it's simpler to just draw what you want into a larger window. That way you only deal with OpenGL, instead of doing that and also having to deal with HTML.

---

However, an option I've thought of but haven't explored yet is to create new popup windows with window.open, approach 3. That way, you could control the size of the initial window that pops up.

However, I haven't tried it yet and don't know how well it'd work in practice. Popup windows are not great in 2016, and they work poorly on mobile devices, etc.

There's another potential use of goxjs/glfw in the browser that isn't supported currently. What if you want to have multiple windows on the same HTML page. That would work with approach 1, but not 2. It'd also work with 3 though.

Just wanted to share my thoughts and context on what I've already tried @Omustardo.

I would classify #8 as a PR that tries to change from approach 2 into 1, but I'm not sure it's a good idea. I'm open to change my mind if there are compelling arguments, but it just seems 2 is the simplest and best overall solution for now. Let me know what you think.

[Omustardo]

I thought about the issue since last posting and came to the same conclusion. Maintaining desktop GLFW behavior in the browser requires taking the whole window. Using only a canvas leads to behavior that doesn't exist for desktop windows, and would be difficult/(impossible?) to work around with the same API.

Having a new popup is an interesting option - arguably most similar to a new desktop window, but I agree that the disadvantages of popups make it not worthwhile.

I've adapted the tetris code to pad the edges and I think it looks much better than before.
https://github.com/Omustardo/tetris/tree/master/webgl-tetris
https://omustardo.github.io/tetris/index.html

Thanks for taking the time to discuss this and for all of the work you put into these libraries. I've really enjoyed being able to put together something graphical on the web, while still working in the clean environment that Go provides.

[meyerzinn]

Sorry to necropost on this, but I've been looking to use glfw for game development in Go (for a 2d, browser-based MMO). I'm considering ways to implement various methods that are currently panicking. What if the browser window is the monitor and the canvas is the window? That would give the most consistent behavior coming from native development. Since changing window size is disabled on most browsers (for good reason), this would allow us to provide consistent behavior (setsize = resize canvas, moveto = set canvas offsets).

[dmitshur]

Sorry to necropost on this,

This is a tracking issue for this subject, it's meant to contain the relevant discussion and planning. So it's completely okay to post here.

What if the browser window is the monitor and the canvas is the window?

Please see and read in full detail my #9 (comment) above. It outlines 3 possible approaches that I've considered, and discusses the trade-offs between them. Approach 1 is the canvas idea you're asking about. goxjs/glfw started off that way, but I moved towards approach 2 because of the reasons outlined in that comment.