Dragging windows halts program

Is there a way so that when the user drags a window (in Linux i’m
testing on) the program doesn’t halt?
I’ve tested it on supertux and it does the same thing. Something to do
with the SDL_PolllEvent ?

And after releasign the window the program will resume.

Is there a way so that when the user drags a window (in Linux i’m
testing on) the program doesn’t halt?
I’ve tested it on supertux and it does the same thing. Something to do
with the SDL_PolllEvent ?

And after releasign the window the program will resume.

This isn’t a problem in SDL. What’s happening is that the window manager
is grabbing the X server during the window drag, so video updates are not
allowed to happen.

Unless you grab the server yourself (and prevent all other programs from
interacting with the display), there’s no way to prevent window managers
from doing this. It’s worth noting that not all window managers behave
that way.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Get another window manager. I’d consider grabbing X a bug, as there’s
no need to except possibly when rendering some stuff. Perhaps an
ugly performance hack to make window dragging look smoother?

BTW, Win32 seems to have a similar bug: Try grabbing a window by the
title bar, and just hold it… On all versions I’ve tried, this stops
the program event loop. (Noticed it becaues it causes drop-outs in
audio programs that don’t use a separate thread for audio.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 19 February 2001 02:27, Nghia wrote:

Is there a way so that when the user drags a window (in Linux i’m
testing on) the program doesn’t halt?
I’ve tested it on supertux and it does the same thing. Something to
do with the SDL_PolllEvent ?

And after releasign the window the program will resume.

which window managers do not act this way? i use windowmaker(although a
rather old version) and it does.

Jess

Sam Lantinga wrote:> > Is there a way so that when the user drags a window (in Linux i’m

testing on) the program doesn’t halt?
I’ve tested it on supertux and it does the same thing. Something to do
with the SDL_PolllEvent ?

And after releasign the window the program will resume.

This isn’t a problem in SDL. What’s happening is that the window manager
is grabbing the X server during the window drag, so video updates are not
allowed to happen.

Unless you grab the server yourself (and prevent all other programs from
interacting with the display), there’s no way to prevent window managers
from doing this. It’s worth noting that not all window managers behave
that way.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

David Olofson wrote:

Nghia wrote:

Is there a way so that when the user drags a window
(in Linux i’m testing on) the program doesn’t halt?

Get another window manager. I’d consider grabbing X a
bug, as there’s no need to except possibly when
rendering some stuff. Perhaps an ugly performance hack
to make window dragging look smoother?

BTW, Win32 seems to have a similar bug: Try grabbing a
window by the title bar, and just hold it… On all
versions I’ve tried, this stops the program event loop.

Oddly enough, if you drag a “different” window, your program happily chugs
along as if nothing is going on. The only one that locks up is the one that
you are dragging. Go figure :slight_smile:

  • Randi

Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net

KDE does by default, but I think you can turn it off. Same with IceWM.On Mon, 19 Feb 2001, you wrote:

which window managers do not act this way? i use windowmaker(although a
rather old version) and it does.


Sam “Criswell” Hart <@Sam_Hart>
AIM, Yahoo!, MSN:
Homepage: http://www.geekcomix.com/snh/
PGP Info: http://www.geekcomix.com/snh/contact/

which window managers do not act this way? i use windowmaker(although a
rather old version) and it does.

IIRC, KWM (from KDE 1) doesn’t, and the same goes for KWin; the KDE 2 WM.On Tuesday 20 February 2001 01:22, Jess wrote:

Sam Lantinga wrote:

Is there a way so that when the user drags a window (in Linux i’m
testing on) the program doesn’t halt?
I’ve tested it on supertux and it does the same thing. Something to do
with the SDL_PolllEvent ?

And after releasign the window the program will resume.

This isn’t a problem in SDL. What’s happening is that the window manager
is grabbing the X server during the window drag, so video updates are not
allowed to happen.

Unless you grab the server yourself (and prevent all other programs from
interacting with the display), there’s no way to prevent window managers
from doing this. It’s worth noting that not all window managers behave
that way.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software


//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

It’s not all that strange, actually. It’s a result the Win32 API being based
on the Win16 cooperative multitasking design. The applications get all
messages passed to their windows, and the “window manager” relies on the
application to get the events back so that it can move, resize,… the
windows.

The reason why the application stalls when you grab the title bar seems to be
some stupid bug that causes Windows to buffer up incoming messages until the
mouse button released, rather than passing them on.

BTW, this also explains why you can’t operate a window of as application that
isn’t responding to messages… I think that’s the single worst bug in the
Windows UI. You have to kill the frozen/working, or just wait if it’s
windows get in the way.

(Note to Windows-only hackers: X windows applications have to explicitly
prevent the window manager from moving windows, or they can always be moved
around, whether the application cares or not, and even if the application is
totally dead.)

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 20 February 2001 06:04, Randi J. Relander wrote:

David Olofson wrote:

Nghia wrote:

Is there a way so that when the user drags a window
(in Linux i’m testing on) the program doesn’t halt?

Get another window manager. I’d consider grabbing X a
bug, as there’s no need to except possibly when
rendering some stuff. Perhaps an ugly performance hack
to make window dragging look smoother?

BTW, Win32 seems to have a similar bug: Try grabbing a
window by the title bar, and just hold it… On all
versions I’ve tried, this stops the program event loop.

Oddly enough, if you drag a “different” window, your program happily chugs
along as if nothing is going on. The only one that locks up is the one that
you are dragging. Go figure :slight_smile:

Jess wrote:

which window managers do not act this way? i use windowmaker(although a
rather old version) and it does.

Well, definitely not the fvwm95/fvwm2 that I use, silly. KDE1 and KDE2 don’t
freeze either.

~jeffrey :j