bug#9366: Display geometry change hook

[Eli Zaretskii <eliz@gnu.org>]

> Cc: larsi@gnus.org, david@harpegolden.net, 9366@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 21 Sep 2020 09:26:01 +0200
> 
>  >> To poll the geometry?  Sounds much too expensive too.
>  >
>  > Same question as above.  We currently have several timers running in
>  > every session, so a timer that ticks, say, once a second doesn't sound
>  > too expensive to me.  Especially since this will most probably be an
>  > optional feature.
> 
> You mean when the value of 'display-geometry-change-hook' is non-nil,
> for example.

Yes.

>  >> If and when the underlying windowing system informs us of display
>  >> changes, I would just react to them.  What's speaking against it?
>  >
>  > The proposed solution was only for X, and using an optional component
>  > at that.  I'd rather find a solution that would work on all supported
>  > platforms and required no special APIs.
> 
> But it would probably rely on 'display-monitor-attributes-list' and thus
> use its APIs.  And on Windows, for example, the "special" API is already
> there in WM_DISPLAYCHANGE and I suppose the other platforms should be
> able to handle fullscreen frames after a display change in a similar way
> too.

Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
the full-screen frames there).  But the corresponding X feature
requires the use of a special X module, and I don't know what happens
on macOS.  So I thought a platform-independent method that always
works, and can be implemented in just one place, is a better
alternative.

Besides, adding one more special event comes with minor disadvantages
of its own -- one more event to disregard in situations like
while-no-input etc.