GLFW geometry constraints

[artificiel]

add support for windows contraints (size and/or aspect ratio). tested in GLFW; ~~GLUT should work (they say to enforce yourself it in the resize callback).~~

not sure how to handle/test other windows? (e.g. in EAGL ofLogWarning() to mention the operation is unimplemented?)

behaves like this with some "adaptive" content: minimum size only:

aspect ratio locked to 4:3 + minimum size:

[artificiel]

update to remove the GLUT attempt (trickier because glut seems more or less static-based, and about to be removed anyway)

[artificiel]

has been extensively used on macOS and no side-effects to report.

[ofTheo]

@artificiel can you test what happens toggling fullscreen when the aspect ratio constraints don't match the fullscreen ratio? also curious when it comes out of fullscreen how if it stays within the defined ratio?

[artificiel]

what happens toggling fullscreen when the aspect ratio constraints don't match the fullscreen ratio?

OK well this sent me in a bit of rabbit hole.... (macOS). ofToggleFullscreen() does not behave like the green fullscreen button in the OS window.

1. through the OS button, there is a zoom effect, and OF gets its own private "space"; the GLFW limits are enforced (essentially letter boxing the app with black borders; good or bad? hard to tell); everything toggles flawlessly back-and-forth.
2. through ofToggleFullScreen() there is no zoom effect, the limits are not enforced (as the size is recalculated by OF) and recovering from fullscreen is somewhat broken (Sometimes they are lost, not always).

i am not in a familiar territory but a bit of googling reveals the way to fullscreen GLFW is to set/unset windows with glfwSetWindowMonitor however OF does not make use of that function — presumably because at one point it did not exist.

as a test, changing the whole ofAppGLFWWindow::setFullscreen() to simply [cocoaWindow toggleFullScreen:nil]; return; makes ofToggleFullScreen work exactly like the window green button.

Incidentally — this is not scientific, but an impression — I've been working on a program that traces slow curvy lines at 60fps (very low cpu, under 10% for the OF process), on macOS M1. when working in "OF Fullscreen", I sometimes feel a little hick-up here and there — but it's subtle, not a raw framerate issue, more like an interruption here and there (difficult to benchmark). Intuitively I made the window "OS" fullscreen (ctrl-cmd-F) and the drawing did not seem to glitch as much.

so now googling led me to macOS game mode https://eclecticlight.co/2023/10/18/how-game-mode-manages-cpu-and-gpu/ — granted this is pretty recent stuff, but it made me wonder. after adding the entry to the plist I was granted this dialog:

pardon the French but you get the keywords: activated, priority, performance — sounds like good things. the link above provides CPU and GPU analysis. all interesting, but it's becoming an involved side-quest.

to come back to this PR: as window contraints mostly make sense only in window mode, perhaps the way to cover it is

1. remove constraints just before going fullscreen (no matter through which mechanism)
2. when leaving fullscreen, restore them (like size/position)
3. when in OF_WINDOW, modify ofSetWindowShape to enforce defined constraints (settings.windowMode does reflect the correct OS-triggered "fullscreen mode" so there is somewhere a callback that works)

on the fullscreen side glfwSetWindowMonitor needs investigation (perhaps it simplifies a lot the heavily platform-ifdef'd ofAppGLFWWindow::setFullscreen) and also this macOS fullscreen needs investigation too, in explicit game mode, but also in simple "OS fullscreen" where I can detect a bit of behaviour difference with my animated lines.

OF should provide at least a way to programmatically trigger macOS fullscreen, which [cocoaWindow toggleFullScreen:nil] does. BUT as this function is a toggle (there is no explicit "direction" parameter), it differs from OF's setFullscreen(bool)— suddenly it seems a larger undertaking to make work correctly without breaking some things. unless it's via a new method ofToggleNativeFullScreen or something like that.

[artificiel]

i am now thinking the GLFW constraints might be ignored and simply handle the constraints internally in setWindowShape and resize_cb. Maybe some funny things will happen if pulling at the extremes (like a 1-pixel fight) but it simplifies dealing with the somewhat hard-to-follow "fullscreen state"...

so basically only point 3 above.