SDL_PollEvent() function strangely impacts rendering

Question

I came across a behavior in SDL3 that concerns me. In SDL3, the standard position of the origin of the screen's coordinate system is in the upper left corner.

I tried rendering a simple 100x100 rectangle in the origin of a maximized window:

#include <SDL3/SDL.h>

int main()
{
    SDL_Window* window;
    SDL_Renderer* renderer;

    SDL_Init(SDL_INIT_VIDEO);
    SDL_CreateWindowAndRenderer("win",800,600,SDL_WINDOW_RESIZABLE,&window,&renderer);
    SDL_MaximizeWindow(window);

    SDL_FRect r({0,0,100,100});

    while(true)
    {
        //SDL_Event event;
        //SDL_PollEvent(&event); <--Only when this line is included will the rendering position be correct
        
        SDL_SetRenderDrawColorFloat(renderer,1,1,1,1);
        SDL_RenderClear(renderer);

        SDL_SetRenderDrawColorFloat(renderer,0,0,0,1);
        SDL_RenderFillRect(renderer,&r);

        SDL_RenderPresent(renderer);
    }

    return 0;
}

To my surprise, the rectangle appeared in on the left side, but in middle height of the screen.

However, only when I added the event polling, would it be rendered correctly in the upper left corner of the screen.

I am very confused about this interaction of the function SDL_PollEvent() and the rendering. Why is this happening?

i take it the OS sent some resize event to set the origin on the drawing area, and you need to call SDL_PollEvent for SDL to internally process OS events and handle them to correctly center your drawing area. — Ahmed AEK
– Ahmed AEK, Commented May 30 at 15:54

genpfault · Accepted Answer · 2025-05-30 18:16:56Z

Failing to process the windowing system's message queue in a timely manner (via SDL_PollEvent() or similar) rarely goes well for a process, usually causing the system to consider it "hung"/unresponsive and offer to terminate it.

From SDL3/SDL_events.h, emphasis mine:

It's extremely common--often required--that an app deal with SDL's event queue. Almost all useful information about interactions with the real world flow through here: the user interacting with the computer and app, hardware coming and going, the system changing in some way, etc.

An app generally takes a moment, perhaps at the start of a new frame, to examine any events that have occured since the last time and process or ignore them. This is generally done by calling SDL_PollEvent() in a loop until it returns false (or, if using the main callbacks, events are provided one at a time in calls to SDL_AppEvent() before the next call to SDL_AppIterate(); in this scenario, the app does not call SDL_PollEvent() at all).

There is other forms of control, too: SDL_PeepEvents() has more functionality at the cost of more complexity, and SDL_WaitEvent() can block the process until something interesting happens, which might be beneficial for certain types of programs on low-power hardware. One may also call SDL_AddEventWatch() to set a callback when new events arrive.

The app is free to generate their own events, too: SDL_PushEvent allows the app to put events onto the queue for later retrieval; SDL_RegisterEvents can guarantee that these events have a type that isn't in use by other parts of the system.

Collectives™ on Stack Overflow

SDL_PollEvent() function strangely impacts rendering

1 Answer 1

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Your Answer

Sign up or log in

Post as a guest

Related