Re: [PATCH-for-9.2] ui/cocoa: Temporarily ignore annoying deprecated declaration warnings

[Akihiko Odaki <akihiko.odaki@daynix.com>]

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 <phil@philjordan.eu 
> <mailto:phil@philjordan.eu>>
> Tested-by: Phil Dennis-Jordan <phil@philjordan.eu 
> <mailto:phil@philjordan.eu>>
> 
> 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.