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

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.

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

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.)

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.

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:

{"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
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.

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:

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.

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.

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.

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.

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

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

I don't see crashes with OpenGL.

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

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

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

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.

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

Ok committed.

GL_NVX_conditional_render, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod,

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).