Re: Display slowness that is painful

[Kim F. Storm]

"Richard M. Stallman" <address@hidden> writes:

>     I traced this to emacs starting to process SELECTION_REQUEST_EVENT
>     events after each redisplay round -- and consequently doing another
>     redisplay...
>
> Why did Emacs get a SELECTION_REQUEST_EVENT at all?
> Normally that should happen only if you try to paste
> into another app some text that you selected in Emacs.
> Did you do that?

No.  When emacs has the selection, it is polled with
SELECTION_REQUEST_EVENTs every seconds by the version of klipper (X
clipboard) that I'm using (this is with KDE on Redhat 9.0).

This version of klipper is buggy according to PROBLEMS:

*** KDE: Emacs hangs on KDE when a large portion of text is killed.

This is caused by a bug in the KDE applet `klipper' which periodically
requests the X clipboard contents from applications.  Early versions
of klipper don't implement the ICCCM protocol for large selections,
which leads to Emacs being flooded with selection requests.  After a
while, Emacs may print a message:

  Timed out waiting for property-notify event

A workaround is to not use `klipper'.  An upgrade to the `klipper' that
comes with KDE 3.3 or later also solves the problem.

>
> When people do that, normally Emacs is idle, not redisplaying
> anything.  Of course, it could be running some sort of program
> that would keep on redisplaying.  Was that the situation?

No.

>
> One other question is, why does Emacs redisplay after handling a
> SELECTION_REQUEST_EVENT?  Is it because this arrives during redisplay
> and pre-empts it? 

It seems so.

>
> Are you saying that Emacs receives a series of SELECTION_REQUEST_EVENTs,
> pre-empting redisplay over and over?  

Yes.  So since redisplay in this case takes longer than 1 second,
redisplay seems to be stalled for a long time -- usually it completes
when I change focus (or move selection) to some other application.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk