4 ms·

> If I open the hood on one of those libraries, I could spend months getting deep enough to contribute. Really? I can understand it in case of missing features

> If I open the hood on one of those libraries, I could spend months getting deep enough to contribute. Really? I can understand it in case of missing features or stuff that needs deeper refactors, but in my experience digging into an external library to debug an issue with it usually ended up with a working patch at most a few days later (usually hours), which is comparable to finding workarounds but with much better outcome. Granted, a working patch doesn't necessarily mean a mergeable patch yet (though it often does for bug fixes), but with FLOSS dependencies you can simply ship a patched version before it gets accepted anyway. Since my stack is fully FLOSS, I tend to look for fixes first before resorting to workarounds and this approach has served me pretty well so far. Even if I fail to come up with a fix in the end, I learn possible workarounds in the process.

Animats 4y ago
Typical issues: * winit - window.with_maximized ineffective on X11 platform * rend3 - Minimize window causes unwrap panic on Windows / Wine. OK on Linux Cross platform full screen is hard. Winit, WGPU, Rend3, and egui are all involved. Some things work on some platforms but not others. Order of operations matters where it shouldn't. (Must be visible before maximized on some platforms, but not all.) Right now I have enough workarounds to continue working. This area is brittle and easy to break. You need direct access to every supported platform (which, for winit, is Linux/X11, Linux/Wayland, MacOS on both x86 and ARM, Android, and WebAssembly) to work on this, and I don't have a full set of target machines. That comes up a lot with the libraries that handle cross-platform issues and present a portable API to the caller. Rust is good about cross-platform portability. It's impressive how well it works. But problems remain.) * egui - Strange scrolling behavior - jitter up and down Egui (a menu/widget overlay system) is under "heavy development". This problem is in the mechanism for scrolling text windows efficiently when most of the text is offscreen, a common choke point in GUI libraries. Need to chase this down. I built a standalone program to demo this, but haven't tried to fix it. This I probably do need to address myself. * sys-locale - Returns "en_US" on Linux. Should return "en-US". One of those little things that breaks other things. RFC 5646 says use "-", and the parser for locales assumes that. Easier to work around than fix, although I reported it. A fix will probably break something that's depending on the current wrong behavior. I don't know enough about the internationalization ecosystem to be confident changing this.
- seba_dos1 4y ago
  > Cross platform full screen is hard. That paragraph is quite fascinating. I mostly work with SDL and Allegro and I've chased a fair share of similar bugs there already on various platforms, most notably fullscreen handling under Wayland, but I never had to care about breaking other platforms with my fixes because platform handling is quite reasonably abstracted away in SDL (and SDL supports a lot of exotic platforms aside of those you mentioned, so it would be pretty much impossible anyway). I don't know winit, I wonder what in its design makes it so troublesome there.
  - Animats 4y ago
    Winit is trying to handle full screen, draggable window with frame and controls, maximized window with frame and controls, maximized window without frame and controls, and minimized window, across various platforms. Then there's the interaction between Winit and the 3D system, which in my case is Rend3/WGPU on top of Vulkan, Metal, OpenGL, or Direct-X. WGPU handles most of the cross platform stuff for 3D. Supported platforms are Mac, Windows, Linux (X11 or Wayland), and Android (Chromebook and phone). Not all the combinations work. To work on this, either someone has to have all the supported hardware, or you need a closely cooperating team who collectively have all the hardware. Mucking about with something like that from the outside is likely to result in breaking something or creating hard to maintain single platform special cases. I'm glad the winit and WGPU teams are doing this. It's important infrastructure used by many projects. It's impressive that it works as well as it does.
    - seba_dos1 4y ago
      So seems like SDL covers everything Winit does plus much more (including at least some stuff WGPU does), and you really don't need to have all supported hardware to work on bugs in it - which would be a nightmare, since aside from the platforms you mentioned it supports stuff like Haiku, PSP, OS/2, Nokia N-Gage or QNX, and even console SDKs behind NDAs that aren't available publicly. Its video drivers and render backends are all separated from each other. In all my adventures with fixing bugs or implementing new features in its Wayland backend (such as HiDPI support) I never had to touch the platform-independent stuff. Not saying that it doesn't happen in general, but I personally never had to do that. It smells like nothing more than a maturity issue. SDL is almost 25 years old at this point.

Animats 4y ago

Typical issues: * winit - window.with_maximized ineffective on X11 platform * rend3 - Minimize window causes unwrap panic on Windows / Wine. OK on Linux Cross platform full screen is hard. Winit, WGPU, Rend3, and egui are all involved. Some things work on some platforms but not others. Order of operations matters where it shouldn't. (Must be visible before maximized on some platforms, but not all.) Right now I have enough workarounds to continue working. This area is brittle and easy to break. You need direct access to every supported platform (which, for winit, is Linux/X11, Linux/Wayland, MacOS on both x86 and ARM, Android, and WebAssembly) to work on this, and I don't have a full set of target machines. That comes up a lot with the libraries that handle cross-platform issues and present a portable API to the caller. Rust is good about cross-platform portability. It's impressive how well it works. But problems remain.) * egui - Strange scrolling behavior - jitter up and down Egui (a menu/widget overlay system) is under "heavy development". This problem is in the mechanism for scrolling text windows efficiently when most of the text is offscreen, a common choke point in GUI libraries. Need to chase this down. I built a standalone program to demo this, but haven't tried to fix it. This I probably do need to address myself. * sys-locale - Returns "en_US" on Linux. Should return "en-US". One of those little things that breaks other things. RFC 5646 says use "-", and the parser for locales assumes that. Easier to work around than fix, although I reported it. A fix will probably break something that's depending on the current wrong behavior. I don't know enough about the internationalization ecosystem to be confident changing this.

seba_dos1 4y ago
> Cross platform full screen is hard. That paragraph is quite fascinating. I mostly work with SDL and Allegro and I've chased a fair share of similar bugs there already on various platforms, most notably fullscreen handling under Wayland, but I never had to care about breaking other platforms with my fixes because platform handling is quite reasonably abstracted away in SDL (and SDL supports a lot of exotic platforms aside of those you mentioned, so it would be pretty much impossible anyway). I don't know winit, I wonder what in its design makes it so troublesome there.
- Animats 4y ago
  Winit is trying to handle full screen, draggable window with frame and controls, maximized window with frame and controls, maximized window without frame and controls, and minimized window, across various platforms. Then there's the interaction between Winit and the 3D system, which in my case is Rend3/WGPU on top of Vulkan, Metal, OpenGL, or Direct-X. WGPU handles most of the cross platform stuff for 3D. Supported platforms are Mac, Windows, Linux (X11 or Wayland), and Android (Chromebook and phone). Not all the combinations work. To work on this, either someone has to have all the supported hardware, or you need a closely cooperating team who collectively have all the hardware. Mucking about with something like that from the outside is likely to result in breaking something or creating hard to maintain single platform special cases. I'm glad the winit and WGPU teams are doing this. It's important infrastructure used by many projects. It's impressive that it works as well as it does.
  - seba_dos1 4y ago
    So seems like SDL covers everything Winit does plus much more (including at least some stuff WGPU does), and you really don't need to have all supported hardware to work on bugs in it - which would be a nightmare, since aside from the platforms you mentioned it supports stuff like Haiku, PSP, OS/2, Nokia N-Gage or QNX, and even console SDKs behind NDAs that aren't available publicly. Its video drivers and render backends are all separated from each other. In all my adventures with fixing bugs or implementing new features in its Wayland backend (such as HiDPI support) I never had to touch the platform-independent stuff. Not saying that it doesn't happen in general, but I personally never had to do that. It smells like nothing more than a maturity issue. SDL is almost 25 years old at this point.