Resize events

[MrDoomMaster]

Hi,

Note first of all that this discussion applies to the Windows platform.

In my specific application utilizing SFML, my themes are set in such a way that the size of the window updates dynamically as the user drags an edge, versus the alternative which only updates the window size after the user releases the edge (in this case you have a light grey outline of the new size to guide the sizing operation).

Due to the way the sizing works, clicking and holding an edge causes the ProcessEvents() function to block until it is released. This continuously fills the message pump with WM_SIZE messages, which in turn causes a ton of sf::Event::Resized events to occur in one iteration of the game loop. Instead, I am only interested in receiving a single Resized event with the final size of the window.

So for example, if I grab the right edge of the window and move it from a size of 800x600 to a size of 800x1000, then I would probably get around 100 or 200 Resized messages. Each message represents a small increment of movement towards the final size. For example:

800x601
800x608
800x610
800x614
......
800x989
800x995
800x1000

As you can see, the only Resized message I'm interested in is the last one. This is why I propose the implementation of a Event::ResizeBegin and a Event::ResizeEnd (or something similar, yet portable).

With a ResizeEnd message, the Event::Size member would contain the size of the final size of the window. Note that internally for performance reasons you may want to find a way to ignore the continuous flood of WM_SIZE messages. They do build up to quite a big collection.

Let me know if I'm on the right track. I want to make sure I'm not misunderstanding anything.

[Mindiell]

What don't you simply put a flag on when getting a resize event ?
After your event loop, you have just to see if the flag is set and do your resizing.

[MrDoomMaster]

What don't you simply put a flag on when getting a resize event ?
After your event loop, you have just to see if the flag is set and do your resizing.

Currently I do that. But it's a hack, not a solution. The (light) performance overhead of the 100-200 needless iterations of my event loop still exists. It needs to be fixed properly.

[dunce]

Is your app's window resizing so frequently that it makes an issue?

[Mindiell]

Currently I do that. But it's a hack, not a solution. The (light) performance overhead of the 100-200 needless iterations of my event loop still exists. It needs to be fixed properly.

In my specific application utilizing SFML, my themes are set in such a way that the size of the window updates dynamically as the user drags an edge

I'm sorry, but SFML is doing its job, it's your application which updates dynamically as the user drags an edge. Maybe you have to change this ?

Due to the way the sizing works, clicking and holding an edge causes the ProcessEvents() function to block until it is released.

If you want to keep this way, the flag is a solution I think, and not just a hack

[MrDoomMaster]

Currently I do that. But it's a hack, not a solution. The (light) performance overhead of the 100-200 needless iterations of my event loop still exists. It needs to be fixed properly.

In my specific application utilizing SFML, my themes are set in such a way that the size of the window updates dynamically as the user drags an edge

I'm sorry, but SFML is doing its job, it's your application which updates dynamically as the user drags an edge. Maybe you have to change this ?

Due to the way the sizing works, clicking and holding an edge causes the ProcessEvents() function to block until it is released.

If you want to keep this way, the flag is a solution I think, and not just a hack

I don't think you understand what I'm saying. My message loop is an exact copy of some of the sample apps using SFML. SFML is so simple, it's pretty much impossible to screw something up like this.

Below is the code I'm using to process messages:

Code: [Select]


bool ProcessEvents( Game& game, sf::RenderWindow& gameWindow )
{
bool closed = false;

// hack to overcome the bug in SFML that causes
// a continuous flood of Event::Resized messages.
// We're only interested in the last one.
unsigned int x,y;
bool resized = false;

sf::Event evt;
while( gameWindow.GetEvent( evt ) )
{
switch( evt.Type )
{
case  sf::Event::Closed:
{
closed = true;
break;
}

case sf::Event::KeyPressed:
{
OnKeyDown( evt, true );
break;
}

case sf::Event::KeyReleased:
{
OnKeyDown( evt, false );
break;
}

case sf::Event::MouseButtonPressed:
{
OnMouseButton( evt, true );
break;
}

case sf::Event::MouseButtonReleased:
{
OnMouseButton( evt, false );
break;
}

case sf::Event::MouseWheelMoved:
{
OnMouseWheel( evt );
break;
}

case sf::Event::MouseMoved:
{
OnCursorMotion( evt );
break;
}

case sf::Event::Resized:
{
x = evt.Size.Width;
y = evt.Size.Height;
resized = true;
break;
}
}
}

if( resized )
{
game.ResizeViewport( x, y );
}

return closed;
}

As you can see, I have placed a hack in to temporarily work around the resize bug. This still seems like an SFML issue. If you see anything wrong with the code above please let me know. Otherwise, I'll be looking forward to this being fixed properly in the SFML library.

Thanks.

[T.T.H.]

MrDoomMaster's question: how to avoid getting a big amount of redundant Resized events in the first frame after the resizing is completed?

My question: how to avoid that blocking so that I can actually redraw my window during the resizing? (and not only having those ugly gray lines)

[MrDoomMaster]

MrDoomMaster's question: how to avoid getting a big amount of redundant Resized events in the first frame after the resizing is completed?

My question: how to avoid that blocking so that I can actually redraw my window during the resizing? (and not only having those ugly gray lines)

Seems like this needs to be in a new thread

[T.T.H.]

Sorry, didn't want to hijack your thread, but I think the answers to those two questions probably are very close together in the code when they'll be implemented. Anyway, you go first.

[MrDoomMaster]

Sorry, didn't want to hijack your thread, but I think the answers to those two questions probably are very close together in the code when they'll be implemented. Anyway, you go first.

True, they probably are. I wanted the main focus to be that there is a backlog of messages in the queue. However, now that you've mentioned it, if the loop doesn't block when you resize I guess it would make sense to constantly be receiving resize events. At least in that case you would dynamically see elements resizing.

So having said that, I agree that the synchronicity of the event loop is probably the essence of both of our problems.