[RFC] Moving some code from GdkFrameClockIdle to GdkFrameClock
GdkFrameClock was initially conceived as an interface, but was later reworked to become a base class: 5f2d1654. Still GdkFrameClock acts like an interface as it contains almost no code beside forwarding to the overrided vfuncs.
As of today we have one implementation of GdkFrameClock: GdkFrameClockIdle
. That implementation uses a timed-wait-based GSource to drive animations. Anyway:
- Timed waits are becoming unsuitable for driving animations on Windows. It used to be possible in the past (at the expense of raising the overall power consumption) via calls to timeBeginPeriod (1) / timeEndPeriod (1) to reach 2ms resolution. GdkFrameClockIdle does that on Windows and reverts to the standard timer resolution (16ms) when done with animations. But since Windows 10 20.04 that method no longer works: 1, 2. Instead, explicit VSync synchronization primitives should be emplyoed. Linux has high resolution timers support since 2009 .ca and that works very well in practice. But even there one could imagine using a real v-sync source.
- Much of the GdkFrameClockIdle code could well belong to the base class implementation
As such I am thinking of moving most of the GdkFrameClockIdle code to GdkFrameClock, in addition to making a specific GdkFrameClock for Windows. Would you be okay with that? Are there any downsides?
/cc @alexl @otaylor @chergert @otte @matthiasc
Thanks!
Edited by Luca Bacci