-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On web, the window module always resizes the <canvas> #339
Comments
Hi Lyra 👋 I think that's a very fair request, I'm definitely open to changing that. To provide some context, up until now, the window module has existed to make it easy to get started, not necessarily to be used for the end application. However, I think most people use it for the end application and there's often not a reason to use anything else. For example, the difference between this and So to me the nicest solution would be if we didn't have to set the size of the canvas at all, that can all be specified another place. I think my reason for doing it like this was that the canvas size didn't take into account the device pixel ratio. That meant rendering to a canvas resulted in a blurry result if the device pixel ratio is not 1. It might also be to make the canvas fill the entire browser window, I don't remember exactly. So this was just my hacky solution because my css skills are.. well.. not very good 😄 do you know if there's a solution for both of these problems in css or html or something? And is it even possible if winit anyway sets the canvas size and there's no way to opt out of that functionality? (We could of course make a feature request to winit) The other solution would be to be able to specify the size explicitly. Wouldn't that be possible by using the already existing window settings min and max size and then update the canvas on resize or something? Maybe a bit confusing to use the window settings for the canvas, but it's kind of like the window on web 🙂 |
I had some time to experiment and it turned out I didn't remember correctly (surprise surprise). On desktop, the To be able to avoid setting the size of the canvas at all, we need changes to |
Ah great! I had started down that path last week, but then I discovered the resize code also lived in
Since opening this issue, I’ve learned that I’d actually need changes to HTML itself for that. 😅 According to MDN, the What I’d need in order to truly integrate my three-d canvas to the page would be a way to update the canvas size when the window is resized – the page has a responsive layout, so if the window becomes narrow enough, I’d want to alter the canvas size. But I think I can handle that from JavaScript now that three-d will stop resizing the canvas on every frame. There is also an open winit issue (rust-windowing/winit#1661) and pull request (rust-windowing/winit#2074) to automatically keep the canvas drawing dimensions in sync with the size of the
That makes total sense to me. I think another nice change would be to refactor this |
Yeah, I actually added that a week ago or something to get the right size before starting the render loop, but it makes more sense that it is applied when constructing the window, not when constructing the context 🙂
Haha, yeah ok, then I guess there's nothing to do about that 😆 The default size really gives you a sense of how old that API is 😄 I think this is also what I remembered about supporting device pixel ratio, I think I had to set both the canvas size in logical and the css size in physical pixels. Took me a while to figure that out.
That makes sense. Let me know if you need anything 👍 I'll merge #340 💪
Oh that would be awesome. But maybe not very easy to do in practice since it's been that long underway?
That's a nice suggestion. I recently separated the window and context creation so you could create the winit window yourself and have full control over it and still easily create a Finally, can you explain a noob what the advantage of
is compared to
|
ah @asny, it’s pretty pedantic, but technically the Window that the canvas appears in may not be the JS global |
Ah, thanks for the explanation. And in this case, I think it's good to be a bit pedantic 🙂 |
👋🏻 Hello!
I’m using three-d’s
window
module, and I’d like to keep doing so – it’s a convenient wrapper aroundwinit
, and I’d rather work with three-d’sFrameInput
andEvent
types.But I’m trying to use three-d to render to
<canvas>
that exists within the layout of its web page, and since 34287bd, three-d resizes the canvas to have the same inner width and height as its parent window. Because this happens unconditionally inrender_loop
, I can’t work around this, even viafrom_winit_window
.I could fork three-d and remove that, but if you’re open to changing this behavior or making it optional, I’d like to start a discussion about how the API could change, and I’d be happy to open a PR to implement it.
winit itself always sets an explicit canvas size, which is also behavior that I wish I could opt out of. But for my purposes, a
size
field onWindowSettings
for wasm targets, or even respecting the existingmax_size
field, would work perfectly.The text was updated successfully, but these errors were encountered: