bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15398: 24.3; Frame redraw completely screwed


From: Lars Ingebrigtsen
Subject: bug#15398: 24.3; Frame redraw completely screwed
Date: Wed, 09 Sep 2020 15:24:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dmitry Antipov <dmantipov@yandex.ru> 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 <jan.h.d@swipnet.se> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]