[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#15398: 24.3; Frame redraw completely screwed,
Lars Ingebrigtsen <=