mdrejhon
commented
1 year ago Ditto.
However, keep support for fullscreen exclusive (e.g. where GLFW siezes exclusive control of the screen on some platforms).
That's required for some applications (e.g. the VSYNC OFF / beamracing ideas posted in #1157).
It also reduces lag/stutter on different-Hz multimonitor systems, since Microsoft Windows is a single-Hz compositor (which means smooth graphics on on screen, stuttery graphics on the other screen) when running in windowed mode or borderless windowed mode on a multiple-Hz system (e.g. 60Hz monitor + 144Hz monitor).
So in a nutshell, all of these need to be support in as cross-platform manner as feasibly possible:
[1] Windowed [2] Boderless full screen window (occasionally-compromised hybrid of windowed and fullscreen) [3] Full screen exclusive (lowest-lag, highest-performance, least-stutter, most control) [4] Offscreen rendering (e.g. #2250)
Both [1] and [2] should be resizeable on the fly or via the OS' standard window-size-set APIs. Although resizeable support of item [2] can vary based on OS to OS. Tons of use cases that only works well with [1], or only with [2], or only with [3], or only with [4], so all use cases needs to exist (#2250 and my comments in #1157 are useful reading to learn about the use cases).
Item [4] is often used for things like streaming or 3D.
The streaming use case (e.g. access to GLFW buffer on headless systems creates a DIY "GeForce NOW" or a DIY "Stadia" or a DIY "Steam Link". Where you use a thin client H.264 device to remotely play a gaming PC.
The 3D/AR/VR/sterescopic use cases that use GLFW workflow seem to use two semi-hacky GLFW instances via item [4] (hacked offscreen contexts) to create the left/right that is sometimes (not always) later merged/multiplexed by a third semi-hacked GLFW instance using item [3] (low latency full screen exclusive) by the 3D developer in the supported 3D format used by the 3D display or VR microdisplay (some use a hidden EDID via things like USB DisplayPort altmode using a special framepacked format) or even pipe to a H.264/H.EVC codec for a 3D VR H.264 stream over WiFi 5/6 (e.g. open source clone of AirLink streaming on Oculus Quest 2 for cordless PCVR removing the HDMI/DisplayPort cable and transmitting the frames over a WiFi H.264/H.EVC stream instead).
With the gradual increase in open source access to VR headsets, keeping GLFW flexibility for [1][2][3][4] is increasingly useful; for developers who want to stay on the GLFW pipeline and workflows;
Especially if Valve releases their merged "Steam Deck" + "Valve Index" standalone headset that competes with Quest 2 (rumor from Discord: ~2025), being the Steam gamestorezilla we love and hate but at least appreciate them being better stewards of Linux than the average game company (FWIW). Their rumored standalone, when it comes out, will undoubtedly be running Linux, and thus benefit huge from GLFW when any of us want to develop VR apps via GLFW, or using GLFW as a porting wrapper from other platforms (e.g. recompile of existing Vulkan-based Oculus Quest apps or PC-based VR apps). And it's also quite possible the same developers may use GLFW to recompile the same software for PCVR (Windows instead of Linux). Making VR porting easier. So prepping the generic API groundwork is key, even if GLFW developers don't have much familiarity with VR (yet).
GLFW also makes recompiling of the same VR application for PCVR and for standalone potentially much easier, with just a few minor changes to GLFW! VR development is so horrendously difficult, so minor changes to GLFW has a overweighted gigantic developer-easing multiplier support if [1][2][3][4] are concurrently offered and centralized into GLFW best-effort.
Many existing game engines (e.g. Unity) are used with GLFW or are used with VR, so making it easier to do both simultaneously is quite golden.
Also item [3] is usually the lowest-latency visible-to-user mode of [1][2][3][4] above, since it bypasses the windows compositor, important for ultra-latency-critical applications such as AR/VR rendering. Interesting side effects such as notification popup windows will work with item [1] and [2] on all platforms but almost never visible on item [3]. (So lowest latency and popup-visibility/ability to Alt+Tab to make an overlay window visible is sometimes diametrically opposed pro/cons).
Most operating system window managers currently supports at least 3 out of the 4 bullet items, and several supports 4 out of 4 bullet items above.
Historically, most of the time this stuff is punted to the end-developer to figure out, but doing best-effort centralizing the crossplatformness of [1][2][3][4] (ideally with success/fail support, or "what-is-supported" discovery built into GLFW for each) is highly favorable, and is right in GLFW's alley because other graphics frameworks are (at least partially) doing it this way -- and now it's kinda high time for GLFW to take the logical baton on this;
So standardizing this into GLFW is definitely hugely favourable... GLFW core developers doesn't necessarily need to know what GLFW users are necessarily doing, or even know VR, or the weird stuff users do, but it would be a gigantic developer-easing to see GLFW movement in this area;
But merely concurrently offering [1][2][3][4] in a reasonably best-effort crossplatform manner, still expands use cases by roughly an order of magnitude, if crossplatform daisychaining GLFW into another GLFW instance is supported (see multiple example of daisychainable combinations in #2250).
dougbinks
Seneral
It would be good if GLFW implemented features on an undecorated window:
These issues are summarized here: https://discourse.glfw.org/t/immovable-resizable-bordeless-window/1586
These features are required because the titlebar is not customizable. Most modern applications will want to reuse the titlebar. Windows supports complete customization of the titlebar in WPF, yet the one drawn with GLFW is old style which doesn't even allow for color customization.
IIRC Electron has this functionality and Flutter does too: https://github.com/bitsdojo/bitsdojo_window
This makes GLFW lag behind modern frameworks. Most of these features seem to be implemented a long time ago for Windows and Linux, and were never merged. It would be good if these features could be merged, because this would significantly modernize the framework for non-games applications.