On 2024/11/21 23:35, Phil Dennis-Jordan wrote:
As we're talking about macOS-only code I'd perhaps have used '#pragma
clang diagnostic' rather than the GCC versions, but clang seems to
understand these just fine too. (Plus, we very much intend for these to
be genuinely temporary.)
Reviewed-by: Phil Dennis-Jordan <[email protected]
<mailto:[email protected]>>
Tested-by: Phil Dennis-Jordan <[email protected]
<mailto:[email protected]>>
I'll try to find some spare cycles to come up with a clean solution to
the deprecation issue towards the end of the year. I need to research
the available alternative APIs for another project anyway.
I think part of the reason for the deprecation is that most modern Macs
(as with other modern laptop and desktop computers) actually use a
variable display frame rate, so the concept of a "native" frame rate is
no longer well-defined. In an ideal world the frame rate would be
something that's negotiable between the host UI and the virtual hardware.
For example, the macOS PV Graphics I've been working on integrating
would actually prefer a "push" arrangement where the guest/PV hardware
notify the host when the next frame is ready, rather than expecting a
fixed-rate frame refresh interrupt or similar. So when using that there
would actually not be any need for the display-linked timer at all if
the UI is happy with the hw calling dpy_gfx_update_full()/
graphic_hw_update_done() proactively whenever it has a new frame
available. I'm not sure what the story is for other display adapters in
QEMU, but I can do a survey of that.
Regarding dpy_gfx_update_full()/graphic_hw_update_done(), it's probably
better to stay the "pull" semantics. With the pull semantics, we can
drop frames when the UI cannot update the output in timely manner
because it's in the power-saving mode or it's just too busy. Adapting to
variable refresh rate will be achieved by using a platform's mechanism
that fires a refresh event at proper timing.
There is also another function we need to care: dpy_set_ui_info(). This
function updates the "mode" of the emulated display to tell the refresh
rate to the guest. A mode is expected to be somewhat stable so it cannot
properly represent the variable refresh rate. A safe option is to expose
the maximum refresh rate via the mode.
