|
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 Agui GUI API -> https://github.com/jmasterx/Agui |
Matthew Leverton
Supreme Loser
January 1999
|
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. Agui GUI API -> https://github.com/jmasterx/Agui |
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.) -- |
Evert
Member #794
November 2000
|
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. |
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 - Do not emit ALLEGRO_DISPLAY_RESIZE events from the Windows and X11 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"} So rather than immediately resize it does the above. It dos not bother to do anything until I lift my mouse up. *Edit *Edit 2 Agui GUI API -> https://github.com/jmasterx/Agui |
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: 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
|
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
|
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 Agui GUI API -> https://github.com/jmasterx/Agui |
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
|
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
|
What was wrong with gluBuild2DMipmaps()? It's probably slower, but shouldn't this be done at program initialization anyway? They all watch too much MSNBC... they get ideas. |
Trent Gamblin
Member #261
April 2000
|
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
|
Ok committed.
|
Arthur Kalliokoski
Second in Command
February 2005
|
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. They all watch too much MSNBC... they get ideas. |
Thomas Fjellstrom
Member #476
June 2000
|
Arthur Kalliokoski said: 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). -- |
|