Thread with 9 posts
jump to expanded post
gods, already had an issue where touchHLE inexplicitly crashed on some user’s machine… because of a misbehaving third-party application trying to display an overlay.
I’m speedrunning all the… /delights/… of being an emulator dev, lol
honestly it’s really depressing that this is actually how stuff like fraps, the Steam overlay, RTSS, and many other gamer overlays work. they just inject themselves into your app’s OpenGL context (or whatever) and fuck around. and sadly it’s not them that find out. it’s you. >:(
hey OS vendors, ban apps from injecting themselves into other apps’ graphics contexts, and instead offer a reliable OS-level way to do overlays, please? pleaaaase? ;_;
@hikari Noob question, as I know *nothing* (and I truly mean nothing) about graphics. But isn't that one of the issues Wayland is trying to resolve on Linux?
@Girgias I don’t know, is it? I’m not very familiar with Wayland tbh, I just know it replaces X and moves a lot of stuff to the app that was previously done by the server.
@hikari Possibly? The fact that each window is a separate context and because compositing is mandatory in Wayland, I would imagine this would prevent some of this interference?
As for me, an overlay is just a thing that composites/decorates on top of an existing, but specific window?
May be saying nonsense tho as I'm not that familiar either. Just that I'm running Wayland on Fedora and sometimes I have weird issue that might be because of that.
@Girgias yeah you’d think that overlays could be handled by the compositor, but to the best of my knowledge, the way all the gaming ones work is by messing with other apps’ opengl/direct3d/whatever contexts instead. this might be because they predate widespread use of composition, but there’s not really a good excuse for them to continue to work that way these days imo
