Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compression of pending same-type events? #2531

Open
cblc opened this issue Apr 8, 2024 · 1 comment
Open

Compression of pending same-type events? #2531

cblc opened this issue Apr 8, 2024 · 1 comment
Labels

Comments

@cblc
Copy link

cblc commented Apr 8, 2024

Is it possible to enable/disable suppression of consecutive same-type events? I mean, imagine that a graphics window is relatively expensive to redraw, and the user starts resizing the window by dragging one of its corners. The application will be receiving a sequence of resize events, but, if the redrawing is expensive, then the events queue will likely have several resize events pending to be processed. It would be nice that there would be a flag such that, if you enable it, pending consecutive resize events are "compressed" into only one (which should be the most recent, so that the window gets the most recent size).

The same could be said for other types of events, such as mouse motion, scroll, refresh, etc...

Of course, a low-level API for the events queue would allow applications to do this, but the nice thing of implementing it with a flag rather than with a low-level API is that existing apps could get this optimization for free without having to rewrite their events management function.

On the other hand, I believe this optimization should be able to be disabled, because some applications might prefer to get all the events.

@dougbinks
Copy link
Contributor

There is no function for this in GLFW, though it could be implemented on top in a number of ways.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants