Does anyone know if it is possible to create an interface with the Scenic UI libraries that uses the full screen. That is, no bounding window frame with minimise and close buttons. I want to occupy the full extent of the screen with my displayed content. In the initial case this would be {1920, 1080} and another of {2560, 1080}.
5 Likes
From what I can tell you would need to add the functionality to the appropriate driver.
For Linux and Mac:
This would be a driver change. Should be doable, although probably not before I see you in Auckland for the meet up. I’m sort of traveling a lot until then.
If you want to take a peek at scenic_driver_glfw, it would be a configuration option, that gets sent to the port. Then it is probably some sort of hint you set. I can look into it in few days.
1 Like
I’ve played a bit with full screen and scenic_driver_glfw, with both fullscreen and windowed fullscreen (aka borderless full screen window), and my findings are:
-
plain fullscreen: basically the video mode is switched to fit your window size, but:
- if you have different aspect ratio between your monitor and your config, black padding will be added
- quality is
meh, basically upsampling your config up to what it fits into the monitor - interaction is shifted in someway… to click on a item you have to click farther on the left. Dunno why, did not investigate, but I suspect some mismatch caused with the aspect ratio or whatever.
-
borderless fullscreen: this is the best, imho, basically you set your window size to the real resolution of the monitor. It works, no interaction offsets, but if your window config is smaller that the monitor resolution, your viewport will be put on the top left of the monitor and all black around (in this mode no upscaling is done, so the lib will put your elements at original size and your window size config is ignored)
Said that, a patch for one of the modes is easy but I did not create one because of the glitches of each one (aspect ratio and offfset issue on the first, window size changed on the second), so I ask to @boydm what thinks about that.
My idea is to permit the second one, is easier and nicer, but with a big fat warning (on docs?) that if you enable full screen, the window size config will be ignored or you have to set at the same resolution of the monitor.
I’m also deliberately ignoring the situation where you may have multiple monitors and assuming that only the primary is used for fullscreen.
Comments?
Reference: http://www.glfw.org/docs/latest/window_guide.html#window_creation
All of this makes sense.
When I think of full-screen mode, the scenario that I care about the most is full-screen on a dedicated device. In that case the software dev is working with the hardware people and should set it to be the native resolution of the screen.
Would like to see the patches you made to enable this. Thinking it would be good to get into 0.10.0 as a feature. (0.9.0 is mostly a docs release and going out very soon)
1 Like
I have a proof of concept here:
but now I’m fighting with Wrong window/framebuffer size for windowed fullscreen in Gnome 3 · Issue #575 · glfw/glfw · GitHub, basically the window and framebuffer starts with a height smaller than fullscreen (on linux, caused by the gnome top panel), and shortly after switches to correct one, reshape callbacks are called but is not redrawn correctly.
Seems that the driver does not handle well reshaping (which basically does not happens at all in windowed mode), so I’m investingating that part.
By creating a normal window, then making it fullscreen, seems to work ok.
I’m suspecting that there’s some issue between glfw and wayland, but I’m not very expert to sort it out.
What do you think?
There appear to be multiple issues with Wayland. Scaling and such. I pretty much don’t know anything about Wayland, so am not making much (any) progress on those things.
