SDL bug which leads to mouse event loss

Hi,

My engine likes to recreate windows in windowed mode under some
circumstances and that causes it to lose mouse click events. This means
the user clicks through the menus and sometimes it just doesn’t work and
you need to click again - VERY annoying (for the end user).

The cause is this bug: https://bugzilla.libsdl.org/show_bug.cgi?id=1992

I cannot think of a proper workaround at engine level right now, so it
would be nice if this could be fixed in SDL. (A workaround at
application level is possible in most cases, but that would require
educating all my engine users on this issue and make them all do
workaround code which would be quite unfortunate - especially since a
workaround imposes some restrictions on window resizing)

Regards,
Jonas Thiem

-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130818/fb89be06/attachment.pgp

Why is this a bug with SDL ?
If you close the window, and their isn’t another window available, then the events should be dropped. SDL has no reason to keep them in memory, and it has no idea you are going to open a new window again.

I assume you close/open the window when they change resolution or something like that?
Why don’t you make a hidden window, in addition to the other window you are closing/re-opening. and then, you shouldn’t lose any events, and you can queue them up.

Yes, this happens to me too on Mac OS X. A workaround is to defer window destruction until a mouse release event, instead of doing it immediately on a mouse press. It might not be a bad idea to do that even without this bug.On 2013-08-18, at 5:32 PM, Jonas Thiem wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please read the bug report carefully, it has detailed instructions for reproducing the bug including demonstration code. Compile and test for yourself to verify: the events lost are clicks happening in the newly created window, at a point where creation is clearly finished and those events should be received again (you can wait various seconds, it won’t change a thing).

The culprit is most likely SDL remembering the mouse being pressed down in the old window, but if you destroy the window while the mouse is pressed down and then create a new window (and release the mouse after destroying the old, but before creating the new one), SDL will still think the mouse is pressed down and subsequently lose/drop the first legitimate mouse down event in the new window, breaking the first mouse click.

Now you might think releasing the mouse exactly between destroying the old window and creating the new one can’t happen accidentally, but in fact it does happen quite easily if the destroy window & recreate happens in a mouse down event.

On 08/18/2013 06:37 PM, Sparks wrote:

Why is this a bug with SDL ?

  > If you close the window, and their isn't another window
  available, then the events should be dropped. SDL has no reason to
  keep them in memory, and it has no idea you are going to open a
  new window again.

  >

  > I assume you close/open the window when they change
  resolution or something like that?

  > Why don't you make a hidden window, in addition to the other
  window you are closing/re-opening. and then, you shouldn't lose
  any events, and you can queue them up.

  >

  >

  > _______________________________________________

  > SDL mailing list

  > SDL at lists.libsdl.org

  > http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSES9eAAoJECgTcNPC9Cd0vGkQAJ/QFE32pLBBqMfAMK2Qrw8l
gFW+yKoIRtLsAWdmbY/RbtURl+o24GcGZyYJnykuOTq9H7HHggiFV9CDXjBn5ejj
lPuf82mi1en/mqQePQ2LDSGVks03UiC6xg/J+yfdxcjgxUjmYAAaV4eowmJmgyji
eM26zZ71FxDA9cruO++EhCJbA3KvGJWJ9qf+/xvXbwWY5KjIWkOwoKZ956q9u17Y
Ilz/+MEz4ENLbneI2+GnthIjftf5L3iFCjhiUvlvSYtPC8UCSFOtjpuULrgLbsLm
7ioMLc98jE0lISWehzU1/OF/G6uFTWfmMK2mu5Sr8tYzUpQZGA1ouLacUmejayjy
w7ArA44Ov/FMUBb3KqmwBX81zedthHaiHB/fsbTvvGkv6UAnXHWG0GW9NG/mmaz+
FETtYYFC1MtoFKqEjDNxznRWzVvE/WA0BWiAGvDeDSkI8/BRvolxvG7/UpSb7xkY
N/rHCOa40JA+kLi3n5kpE8g24Lk6zv8FzqaItnnQXdRX2aF4ls4zaOBggZTDsmRG
p0iUzBF4zRga/Ju95qiF6/+SnH+e0Rsk+Rgr/0K40p5Fx8NXJaMVarPf83AUNyvv
YXB2OZsU7b9oTwmKBBYuM7VC5sxmFhG2reTbVFjVLXldN/Mih3TVlF+kiCq/IWXk
jxqgf59CRM/7qQx/YOBZ
=Zb6f
-----END PGP SIGNATURE-----


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jonas Thiem wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please read the bug report carefully, it has detailed instructions for reproducing the bug including demonstration code. Compile and test for yourself to verify: the events lost are clicks happening in the newly created window, at a point where creation is clearly finished and those events should be received again (you can wait various seconds, it won’t change a thing).

Whoops, [Embarassed] I read that wrong, guess I needed more coffee!

Message-ID: <5211314D.2010901 at googlemail.com>
Content-Type: text/plain; charset=“iso-8859-1”

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Due to engine design, I can’t do that easily since basically the
application decides whether to do this on mouse down or mouse up (and I
would need to freeze the whole application to avoid trouble when I
delayed this, since the application expects it to happen instantly when
it requests the window change) - so I’d need to have all application
devs be aware of this or do some really ugly trickery in the engine to
avoid it.

Having not tested (does this really only happen on Linux,
incidentally?), I can’t say that this would fix the matter, but purely
out of curiosity: why don’t your menus react to mouse-up locations
instead of mouse-down? Ignoring the question of whether that would fix
the bug, I would think it would be better from a UI standpoint: if
someone changes their mind, or accidentally clicks the wrong thing,
they could simple move the cursor somewhere else before releasing.> Date: Sun, 18 Aug 2013 22:40:45 +0200

From: Jonas Thiem
To: SDL Development List
Subject: Re: [SDL] SDL bug which leads to mouse event loss

Yes, this bug should be fixed. Is it in bugzilla already? Is there a
proposed patch for it?On Mon, Aug 19, 2013 at 9:18 AM, Jonas Thiem wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah menus could react on mouse up, but I’m writing an engine and this
decision needs to be made by the application dev. So basically as an
engine author I am aware of this SDL bug but I can only pass it through
to the application devs to have them work around it. Not really a neat
situation.

But I suppose we shouldn’t discuss engine politics too much here. I
suppose at some point it just should simply be fixed :slight_smile:

On 08/19/2013 02:02 AM, Jared Maddox wrote:

Date: Sun, 18 Aug 2013 22:40:45 +0200
From: Jonas Thiem
To: SDL Development List
Subject: Re: [SDL] SDL bug which leads to mouse event loss
Message-ID: <5211314D.2010901 at googlemail.com>
Content-Type: text/plain; charset=“iso-8859-1”

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Due to engine design, I can’t do that easily since basically the
application decides whether to do this on mouse down or mouse up (and I
would need to freeze the whole application to avoid trouble when I
delayed this, since the application expects it to happen instantly when
it requests the window change) - so I’d need to have all application
devs be aware of this or do some really ugly trickery in the engine to
avoid it.

Having not tested (does this really only happen on Linux,
incidentally?), I can’t say that this would fix the matter, but purely
out of curiosity: why don’t your menus react to mouse-up locations
instead of mouse-down? Ignoring the question of whether that would fix
the bug, I would think it would be better from a UI standpoint: if
someone changes their mind, or accidentally clicks the wrong thing,
they could simple move the cursor somewhere else before releasing.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSEkVyAAoJECgTcNPC9Cd05IUQAMMLKzu1+RUauR4Rau/5WcWP
lwE5sukOLh0vy6rCimvDBHNkXzFXystu9PVsz08FDbaAkg32ZqrfIPg9a1X6sO/e
ArC3rEtNLSIfXJ0/2D8gv8+GmMMZIlC2ey8ZetJwVv1RZE+jJ87mOsQDLX77qm10
s+BT8OQ2vscgYiDe7MkF5fv3Q9nvXCf1LJVAOODg2pstJBPwY2mF2OutETUnabKl
aMf3XzmxoQ6m7YSm9Van8idhWH3FbXL2MbhVGf2YvNAK3yJLJGtzTqS0BzqIihKD
tQsP3O+VI6oMrcsyqovpD3EBmoxkqZsH8rOY9LJOhyRAkhaF7b5g/zUsW85/6MZ/
03vqxrqk7Jrc2WAT/a+n0ltluXVO2m3kcjUdtQUTjJnKVX0JFw4VPetmitH72Eek
/Pevhhr29Pg0PYZwQydvYvdpKhuRdKwTE3c1g+AobrafL6C0M/xyZCjsukcStYe2
o30H1csizLBLgZswCTp1PVM9M8TywG8eDIXNdLyr3zqN4EUKHukXfsH2xtOC7hZh
kLG5Qeu7mSAyC6CNylLIXbU3bZjggZiL3XPF2YRWPrARfOqsOCscbicaGdcUu66f
1PiwAQdHDGkSAUPMtmRWe2Tz7jRFgAxlFgQj2gaeWOKqhn0eEqESkUih1noOZj16
Xn9Y2bwg6IBudLVoFx0n
=ctl/
-----END PGP SIGNATURE-----


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yeah menus could react on mouse up, but I’m writing an engine and this
decision needs to be made by the application dev. So basically as an
engine author I am aware of this SDL bug but I can only pass it through
to the application devs to have them work around it. Not really a neat
situation.

But I suppose we shouldn’t discuss engine politics too much here. I
suppose at some point it just should simply be fixed :slight_smile:

I am happy you have because it is not a view application developers appreciate
easily.On 20/08/2013, at 2:18 AM, Jonas Thiem wrote:


john skaller
@john_skaller
http://felix-lang.org