Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Why are resize events now queued instead of instantly done?

This thread is locked; no one can reply to it. rss feed Print
Why are resize events now queued instead of instantly done?
jmasterx
Member #11,410
October 2009

Before, I think around 4.9.22 or RC1, when I resized in Windows, or Mac, it instantly resized on the fly, and if it was not fast enough it queued them up. Now, it always queues them up even if it can handle it. I was wondering why it is this way now. Isn't the other way more aesthetically pleasing?

What I mean is if for example you have text that wraps to your window, it happened as you dragged it instead of waiting until you are done dragging the Window.

Thanks

Matthew Leverton
Supreme Loser
January 1999
avatar

Related thread.

Personally, I would prefer to get the events as often as they come. If dual behavior is useful, then perhaps a flag could be set on the final release. i.e., An event is triggered as the window is resized. When the user releases the mouse button, then one final event is triggered with a flag set.

If the programmer chooses to process each intermediate resize, then he should be responsible for peeking ahead to see if there's already another event that supersedes his current one.

jmasterx
Member #11,410
October 2009

Yes I agree, there should be some sort of display flag.

Elias
Member #358
May 2000

This sounds like a bug to me - as far as I know we always wanted resize events to occur immediately. (Unless you use a WM which simply doesn't send a resize before you release the mouse, like Gnome with Compiz enabled. I think at least that's one who doesn't, can't check right now.)

--
"Either help out or stop whining" - Evert

Evert
Member #794
November 2000
avatar

jmasterx said:

Before, I think around 4.9.22 or RC1, when I resized in Windows, or Mac, it instantly resized on the fly, and if it was not fast enough it queued them up. Now, it always queues them up even if it can handle it. I was wondering why it is this way now. Isn't the other way more aesthetically pleasing?

I'm not entirely sure what you mean, but the OS X code hasn't changed between those versions. It's always posted an ALLEGRO_EVENT_DISPLAY_RESIZE whenever we get a viewDidEndLiveResize from the OS, which is probably the best you can get.
Checking whether the mouse button has been released after a resize operation sounds unreliable to me, since I can imagine that the OS won't tell us that the mouse button was pressed or released at all if we're starting a resize operation.

jmasterx
Member #11,410
October 2009

Yea after testing, it seems ike it is a Windows issue, both with D3D & GL

it might be these changes from 4.9.22 to 5.0.0rc1:

Quote:

- Make al_resize_display keep the original resolution (or change back) if it
can't set the users request, on Windows.

- Do not emit ALLEGRO_DISPLAY_RESIZE events from the Windows and X11 display
drivers when using al_resize_display.

{"name":"602918","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/e\/2e7f27cc7c33842b8a346c8f61b917b8.jpg","w":963,"h":641,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/e\/2e7f27cc7c33842b8a346c8f61b917b8"}602918

So rather than immediately resize it does the above.

It dos not bother to do anything until I lift my mouse up.

*Edit
Yea just realized that on Windows with RC3, when I drag the Window, I will never get an ALLEGRO_EVENT_DISPLAY_RESIZE until my mouse is released. I find it to be a pretty big issue because they are queued up and so if I dragged the window for 30 secs trying to get it to my liking, it will take around 30 secs for the game to be playable again. This does not happen in 4.9.22 .

*Edit 2
Has this issue been addressed yet in RC4? I know a few people that are using AL5 that are asking me the same thing. It is ridiculous that in release build the user has to wait ~20-30 seconds before it resizes. It should be consistant with how OSX and Linux work imo.

Peter Wang
Member #23
April 2000

The problem is NOT what you think: we are not postponing resize events; they are being added to the event queue as soon as possible. What changed from 4.9.22 to 5.0.0rc1 was this:

Quote:

Move the Windows event loops back into the same thread as the D3D event loop. It's a requirment of D3D, else you can get crashes as I was when resetting the device (like tabbing away from a fullscreen app).

I'm not a Windows expert, but so far as I can tell, the main thread (i.e. where you call al_wait_for_event from) is not executing during a window resize, so it never gets a chance to process the resize events until the resize interaction is over. Trent could probably tell you if that makes any sense.

Related reading:
http://www.gamedev.net/community/forums/topic.asp?topic_id=488074

If it really is unfixable as it sounds, we might need to start postponing resize events, so you don't end up with a huge batch of them at once.

Trent Gamblin
Member #261
April 2000
avatar

I'm not an expert either, but the message loop definitely does have to be in the same thread as the d3d display was created. I don't feel like searching for the documentation that says that right now, but trust me, it's on MSDN somewhere. It doesn't say anything about OpenGL (It's in the D3D docs).

Reading that gamedev thread, it seems like there is no clean solution. However, in my own tests (not recent ones, I'm on holidays!), after moving the message loop back into the d3d thread, I found that the display did update when resizing it, just not regularly... I found if I pause mouse movement for a bit it would refresh the display. I didn't test moving the window but don't recall any problems. This seems to be reflected in that gamedev thread as there someone says that some events are passed back up to the main window callback like WM_SIZE.

Secondly, I found that when using OpenGL, resizing wasn't perfect but not nearly as bad as D3D. The display would get updated often enough that it wasn't a complete mess.

I don't know if there's anything we can do about it. I'm open to suggestions.

Peter Wang
Member #23
April 2000

I've started a patch to defer resize events between WM_ENTERSIZEMOVE..WM_EXITSIZEMOVE. It works better here on my machine, though it wasn't my intention. Give it a try.

Trent Gamblin
Member #261
April 2000
avatar

The patch makes ex_resize2 work well enough with Direct3D. OpenGL is worse though. Before the patch ex_resize2 works well enough with OpenGL here.

An aside, has anyone noticed that most of the examples crash now using OpenGL? For example, ex_bitmap and ex_draw_bitmap crash when I force the OpenGL driver on Windows.

jmasterx
Member #11,410
October 2009

Well at the worst you could maybe discard all the other resize events and only keep the release one. If you're not planning to show the result until its done, might as well only process the resize event once.

Although it does look cooler to have dynamic, on the fly resizing. But it's okay if it cannot be done :)

Peter Wang
Member #23
April 2000

Trent: I will make the patch conditional on D3D then.

I don't see crashes with OpenGL.

Trent Gamblin
Member #261
April 2000
avatar

The crash is coming from glGenerateMipmap. I only seem to have glGenerateMipmapEXT here.

Peter Wang
Member #23
April 2000

I thought they were synonyms. We can use glGenerateMipmapEXT if that works.

Arthur Kalliokoski
Second in Command
February 2005
avatar

What was wrong with gluBuild2DMipmaps()? It's probably slower, but shouldn't this be done at program initialization anyway?

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Trent Gamblin
Member #261
April 2000
avatar

glGenerateMipmapEXT works. Will that work everywhere? I'm not sure if I can just commit that change or if it will break for other people.

Peter Wang
Member #23
April 2000

It's in the FBO spec so it should work.

Trent Gamblin
Member #261
April 2000
avatar

Ok committed.

Arthur Kalliokoski
Second in Command
February 2005
avatar

Quote:

pepsi@fractalcomet:~ 08:17 PM $ glxinfo | grep -i mipmap

GL_NVX_conditional_render, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod,

OTOH, fbo isn't found.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Thomas Fjellstrom
Member #476
June 2000
avatar

OTOH, fbo isn't found.

Then you don't have a problem, allegro will not use FBOs if your GL doesn't advertise their use in some form (extension list, or the version of GL itself).

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Go to: