User code cannot distinguish live-resize expose events from regular ones

[slime73]

I have live resize implemented in my 'traditional' style / while-loop-and-polling app, via an SDL event watcher that listens for SDL_EVENT_WINDOW_EXPOSED and redraws.

This sort of works but introduces issues including stuttering during resizes, because the app ends up redrawing from inside the SDL_EVENT_WINDOW_EXPOSED event in situations where the event didn't originate from a live-resize OS notification, and those situations can be pretty frequent even during a resize.

I'm testing a local change to SDL_OnWindowLiveResizeUpdate which just sends 1 instead of 0 for the event.window.data1 event field. When my code detects that and only redraws if it is 1, the issues I've been having go away.

If that change is desired, I could make a pull request for it - I think it shouldn't introduce any backwards incompatibilities since the data1 field wasn't being used for anything meaningful in the expose event before. Or if people have better ideas I'm interested in those too. :)

The code in SDL is here:

SDL/src/video/SDL_video.c

Lines 4136 to 4145 in 7d9fd48

	void SDL_OnWindowLiveResizeUpdate(SDL_Window *window)
	{
	if (SDL_HasMainCallbacks()) {
	SDL_IterateMainCallbacks(false);
	} else {
	// Send an expose event so the application can redraw
	SDL_SendWindowEvent(window, SDL_EVENT_WINDOW_EXPOSED, 0, 0);
	}
	SDL_PumpEventMaintenance();

I haven't looked much at how it all works with a callback-style app instead of a traditional one, so I'm not sure if a similar idea would be useful there or not.

[slouken]

Sure, go ahead and create a PR for this.

[slouken]

BTW, you generally should be redrawing in response to expose events... that's why they exist. :)

[slime73]

BTW, you generally should be redrawing in response to expose events... that's why they exist. :)

I thought so too, but I found out that if an app also intentionally redraws every frame as well, it creates some weird situations where redrawing can happen more frequently than expected (like on Linux which has its own live resize not triggered by SDL) or in situations that can't always work in generic code (like if a frame is run inside an event generated from a code-driven resize done from inside a frame's update or draw code, the apparent order would be events -> update -> events -> update -> draw instead of events -> update -> draw -> events -> update -> draw - whereas some app code can rely on the latter).

In any case, I'll make the PR, thanks!