Subject: bug#15398: 24.3; Frame redraw completely screwed

From: Lars Ingebrigtsen <[email-masked]>
Date: Wed, 09 Sep 2020 15:24:27 +0200

Dmitry Antipov <[email-masked]> writes:

>> I don't recall all the details, but I think the comment actually
>> means "for GTK 2.6 and newer".
>
> Ugh. Reverted in r114402 (for visible frames; in general, I think
> that it is possible to handle Expose events a bit more intelligently).

If I'm skimming this thread correctly, this revert fixed the reported
bug, so I'm closing this bug report.  If there's more to be done here,
please send a message to the debbugs address, and we'll reopen.

Jan Djärv <[email-masked]> writes:

>> Yes, mixing Xlib and Gtk is ugly. But I would like to get your
>> comments on this first
>> (also I'm looking for brave testers).
>> 
>> Dmitry
>> 
>> <gtk_clear_expose.patch>
>
> This simply does not work.  It assumes there is only one frame per
> root window, which is wrong.
> It assumes Emacs will get Unmap events when something obscuring it
> goes away, this is wrong (other applications may cover Emacs and the
> go away).
>
> Any optimization attempt in this area is futile, it will lead to
> errors for a very small performance benefit.  The time is better spent
> into doing a proper double buffer solution.

And I think Emacs got that in the years that followed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no