Re: master cc29fab3a6: Redisplay "invisible" frames that are actually visible on modern X

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> FWIW, while this sounds about right for `icon`ified frames, for those
>> frames that are marked as actually invisible, I think we should try and
>> keep them as invisible as possible.
>
> I'm not sure I agree.  I believe this could belong to some new GUI
> ideas (all of which are invariably copy-cat'ed from MS-Windows ;-),
> whereby you have a means of showing a small-but-still-readable image
> of an otherwise invisible frame, e.g., by hovering the mouse above
> some desktop icon or widget.

If there's some representation of that frame somewhere on the screen,
then I think it belongs in the `icon`ified state, not the
`invisible` state.

> If that is the intent,

In my experience the intent of `invisible` frames is for them to be
literally invisible as if the frame did not exist at all.
Quoting from the docstring of `make-frame-invisible`:

    On graphical displays, invisible frames are not updated and are
    usually not displayed at all, even in a window system’s "taskbar".

> But I do think this should be an optional feature (we could argue
> later about the defaults).  In an Emacs session with a dozen
> invisible/iconified frames, updating those frames without the user's
> say-so could be a misfeature and a performance hit.

Hmm... didn't think of that aspect, but indeed, my Emacs sessions usually
grow to around a hundred frames, the vast majority of which are `icon`ified.
The usual redisplay optimizations should hopefully keep the performance
impact in check, tho (except for those iconified frames that display
a buffer that's changed in the background, I guess).

Rather than rely on "optional feature", would it be possible to rely on
"expose events" to detect when an iconified frame needs to be updated?


        Stefan