GNU bug report logs - #15398
24.3; Frame redraw completely screwed

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 15398 <at> debbugs.gnu.org, Jan Djärv <jan.h.d <at> swipnet.se>, Samium Gromoff <_deepfire <at> feelingofgreen.ru>, Serge Kosyrev <skosyrev <at> ptsecurity.ru>, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: bug#15398: 24.3; Frame redraw completely screwed
Date: Wed, 09 Sep 2020 15:24:27 +0200

Dmitry Antipov <dmantipov <at> 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 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.