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

Eelium GUI needs to handle double buffering correctly #132

Open
olofson opened this issue Feb 27, 2020 · 0 comments
Open

Eelium GUI needs to handle double buffering correctly #132

olofson opened this issue Feb 27, 2020 · 0 comments

Comments

@olofson
Copy link
Owner

olofson commented Feb 27, 2020

All hardware accelerated rendering is double buffered with SDL2, which complicates matters for applications that expect to do "smart updates" on the widget level. gui.Refresh() is currently supposed to only update areas that have actually changed, returning an array of dirty rectangles. This is problematic, as we don't know if there is more than one buffer that needs to be updated.

Further, even in some windowed environments, double buffering is either implemented via page flipping, or the off-screen buffer is occasionally erased or corrupted. That is, it's never really safe to assume anything about the buffer!

Is it even possible to reliably detect whether or not gui.Refresh() needs to invalidate the whole target, or if it's safe to redraw only changed areas?

I suspect that it pretty much boils down to always repainting the full target on updates, unless you happen to know exactly what you're running on. Smart refreshing is better handled by "lightweight windows" on the windowing system level. (Currently not directly supported by SDL2, AFAIK, but should be possible to implement per-platform via SDL_CreateWindowFrom().)

@olofson olofson changed the title Eelium GUI needs not handle double buffering correctly Eelium GUI needs to handle double buffering correctly May 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant