XShm driver paints a transparent background

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]

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?