v0.4.0 - Rendering overhaul

Breaking Changes

WindowHandler::on_frame is now WindowHandler::draw, and is now called lazily instead of systematically

This is the biggest change in this release: the WindowHandler::on_frame method has been renamed WindowHandler::draw, in order to highlight two major changes in how it's used by platforms under the hood.

First, this method is no longer called systematically at every frame interval.
Instead, in order to save resources, it is only scheduled to be called on an as-needed basis.

It is scheduled automatically by the platform when the window contents have been damaged or lost (e.g. on first show, during a resize operation, or if the window has been obscured by another in non-composited systems).

It can also be scheduled explicitly by the WindowHandler by using the new WindowContext::request_redraw (or WindowContext::request_redraw_after(duration)). It can be done as a response to any event (input or otherwise), and if scheduled from within WindowHandler::redraw itself, then a new draw call will be scheduled at the next frame to allow for smooth, continuous animations and transitions.

This optimization used to be done by WindowHandler implementations themselves (including in baseview's own examples), however doing this without deeper integration with the platform would cause it to "miss" damage events, causing the window to first appear blank in some situation (e.g. after minimizing, on first show, etc.).

Because it is not called regularly anymore, WindowHandler implementations should not use draw to poll external event sources, such as queues, atomics, etc. You should use the new poll handler for this instead (see below).

Second, platforms now expect drawing to be done synchronously within the draw callback (if any drawing has to be done at all). More specifically, drawing should not be performed outside of this function, and should not be deferred either. Drawing should be complete when the WindowHandler::draw method returns.

This allows for proper frame pacing (to avoid stuttering), and also to avoid tearing on the edges of the window during resizing operations, by being able to provide synchronization with the window manager between drawing the window contents and decorations.

See the documentation for the WindowHandler::draw method for more details.

New feature highlights

New WindowHandler::poll callback

As mentioned above, the new WindowHandler::poll callback can now be used to poll events from non-platform sources, for instance queues and buffers from an audio processing thread.

This callback is called systematically called before each frame, but is otherwise untied to the actual frame interval (i.e. it can be called earlier, or multiple times per frame interval if needed). It should be seen as a lightweight check to see whether redrawing a new frame is needed, and can call WindowContext::request_redraw if so.

Moreover, this callback can also be scheduled from outside of the WindowHandler itself, by using the new Window::request_poll function, or the same method the new WindowWaker handle.

New WindowWaker handle

This is a simple, weak handle to the window, which can be sent and used across threads to "wake" the window up from external events, by either scheduling a call to poll or requesting a redraw at the next frame interval.

These can be created directly from either the Window or WindowContext types, depending on your needs.
See the external-wakeup example to see it in action!

Full and partial Window damage notification support

While the new drawing system only calls draw when needed to preserve resources, some renderers can go even further and support rendering only the portion of the window that changed instead of the whole frame.

These can now be integrated to the platform using the new WindowHandler::damage callback, informing the renderer of areas the platform and/or window manager need to be redrawn.

---

Full Changelog: v0.3.6...v0.4.0