search

HumbleUI / JWM

Cross-platform window management and OS integration library for Java
Apache License 2.0
570 stars 46 forks source link

Question: Why was GLFW not used as the base underlying API? #257

Closed bmitc closed 1 year ago

bmitc commented 1 year ago

Hello! This is more of a discussion question, but Discussions aren't enabled on this repository. So I thought I would post an issue here clearly marked as a question. 🙂

My question revolves around the reasons why GLFW was not chosen as the base window API. The README states (enumerated here for reference):

GLFW via LWJGL, SDL2:

  1. Game-oriented
  2. Bad window management
  3. No OS integration
  4. Create one window and go full-screen is the main use-case

(1) is true regarding the main users (I think?), but it doesn't seem overly represented in the API that I can see.

(2) There is no window management in GLFW, so it's not necessarily bad. It just allows you to come up with your own. Do the various platform-specific window APIs come with window management? Don't you have to create your own cross-platform window management anyway?

(3) What OS integration is GLFW missing?

(4) This relates to (2), but there is certainly the ability to create multiple windows and your own window management.

My reason for asking is here is that I am embarking on a project that does cross-platform windowing and drawing (not in JVM land), and so I am genuinely curious why GLFW wasn't picked for JWM. I am currently using GLFW, and I don't see any issue or limitation with it, at least not yet. My assumption would be that one would basically have to rewrite the functionality of GLFW anyway to do cross-platform windowing. So I'd like to better understand where my assumptions are wrong and fill in pieces of my knowledge of what the platform-specific APIs and custom wrapping them might provide over GLFW. I do not have deep familiarity with the platform-specific window APIs (Win32, Cocoa, X11, Wayland).

Thank you so much for any information you can provide! I understand any information I get is a freebie, so I very much appreciate it.

tonsky commented 1 year ago

Well, for my use-case (cross-platform UI framework) I needed:

See for yourself, maybe if you don’t need all that, it might work for you. After all, it’s a well-know and used library

bumfo commented 1 year ago

@tonsky About the refresh rate on different monitors, what do you think is the intended behavior of JWM, when one is 60Hz, and another is 144Hz (very popular for 3rd-party displays recent days).

tonsky commented 1 year ago

@bumfo window should re-render at native monitor refresh rate, synchronized with vsync. From my experiments, only macos and wayland support different refresh rates on different monitors, both windows and x11 just set the same rate IIRC

bumfo commented 1 year ago

@bumfo window should re-render at native monitor refresh rate, synchronized with vsync. From my experiments, only macos and wayland support different refresh rates on different monitors, both windows and x11 just set the same rate IIRC

Do you mean JWM already supports different refresh rates on macOS, what a good news for me ;). Btw, is that possible to support this as well on windows & x11, e.g. do you know any frameworks that does this correctly.

tonsky commented 1 year ago

No, I mean Windows and X11 themselves don’t support different refresh rates

tonsky commented 1 year ago

Yes macOS should work already

bmitc commented 1 year ago

Thanks for all the information here! Just some small follow-ups, and I'll go ahead and close this issue so that it doesn't clog up your actual issue pipeline.

  • Metal for macOS

For Skia, it is my understanding that Metal can be had through Vulkan and Molten. Or are you needing or preferring direct access to Metal or using something other than Skia? (Or I guess not wanting to be bound to Skia.) For my uses, I simply can't go any lower than Skia (or some as of yet unknown alternative), so I'm happy to let Skia handle everything (if it can, right now hitting some issues).

  • Tight OS integration (e.g. notifications, native fullscreen, window styling, menubar, accessibility, IME, color management etc

Is the idea that GLFW doesn't provide these, intentionally of course, and so you would need to write platform-specific wrappers and a generic library anyway for all those needs, so why not just extend such effort to windowing as well?

Thanks again for any information and advice. Even with Skia and GLFW, I've had a lot of issues, but none of them with the actual GLFW library. Currently trying to figure out Skia (namely SkiaSharp) and possible OpenGL driver issues. So much issues that I have threatened to go Windows only as I just want to do what I originally wanted (I just don't have the guts to deal with other GUI frameworks and their complexity).