search

bsnes-emu / bsnes

bsnes is a Super Nintendo (SNES) emulator focused on performance, features, and ease of use.
Other
1.69k stars 158 forks source link

XShm driver paints a transparent background #120

Open ghost opened 3 years ago

ghost commented 3 years ago

VideoXShm::clear is a bit buggy. inputWidth and inputHeight aren't set until after the first call to VideoXShm::output(), so the buffer doesn't get its alpha bits set, and the result is you see through the bsnes window onto the desktop.

https://github.com/bsnes-emu/bsnes/blob/master/ruby/video/xshm.cpp#L38

My proposal is to use the acquire function inside clear to ensure the input buffer size is non-zero, then fill that array.

If you guys approve, I'll submit a patch. Otherwise I'll leave it to you all.

Screwtapello commented 3 years ago

I can't reproduce that problem here in i3 (even with a compositor running) but this is a pretty classic failure-mode for apps that don't expect RGBA visuals, so I'm not at all surprised. Probably it manifests on floating-style window managers with compositors, like GNOME or XFCE.

My proposal is to use the acquire function inside clear to ensure the input buffer size is non-zero, then fill that array.

So, when clear() is called, resize the video buffer to, say, 1x1 and colour the lone pixel black? That makes sense. Is clear() called regularly, causing regular resizing to add overhead? Should the driver just be updated to initialise the buffer to 1x1 instead of 0x0, and save messing with clear() at all?