[Top][All Lists]

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

Re: Problem copying large text under X

From: Jan D.
Subject: Re: Problem copying large text under X
Date: Fri, 05 Nov 2004 08:20:38 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916

Kim F. Storm wrote:
"Jan D." <address@hidden> writes:

After a (long) while, it does seem to terminate the clipboard protocol
and things are back to normal performance.

It could seem like the clipboard program (KDE klipper) is slow,
but it does seem to get the whole data eventually.

FWIW, klipper on KDE 3.3 does not seem to have this problem, it
completes almost instantly.

So does it here -- but it seem to immediately requst the same selection
again.  Actually this happens even if I just copy 3 bytes with M-w.

Here's output when I enable TRACE_SELECTION in xselect.c

6469: Sending all 76 bytes
6469: Sending all 3 bytes
6469: Sending all 76 bytes
6469: Sending all 3 bytes

etc. etc. etc.

So copying to the clipboard works fin -- it just sends it again
forever, because it's asked to do so!!!

Look very much like a bug in klipper, but parhaps there's a way
to make it stop.

Here's the trace for the full xdisp.c [there's additional trace output
that I added, but I suppose you get the picture].


etc. etc. ad infinum.

Thanks, I know now what happens. The X selection mechanism where designed so that transfer between X clients should only happen when needed, i.e. one client wanted the selection data. If no client asks for selection data, the X server simply keeps track of the owner of the selection data (not the data itself), and informs other clients when the owner changes. Programs like klipper goes against this design, in that they wish to transfer the selection data everytime it changes regardless of anyone who uses klipper asked for it. It would be one thing if they got the selection data and then became the owner of the selection, but they don't, the owner is still the original client (Emacs).

Here is where klipper runs into trouble, there is no X protocol request that tells klipper if Emacs has changed the selection data (another part of text is selected for example). The owner is still Emacs, so from an X point of view, nothing has changed. So to figure out if the selection data is the same, klipper polls Emacs. I've looked at the source, in kde 3.1.5 klipper gets the whole selection data (the whole xfns.c file in this case) every second and compares that with the previous request. In more recent kde (like 3.3), klipper instead of getting the whole selection data just gets the TIMESTAP of the selection (4 bytes), and compares the timestamps instead. Hence, 3.3 is so much faster, but there is still polling as you discovered.

I don't see any Emacs bug here, nor any way to stop klipper from polling (I didn't find any configuration option in klipper for this).

I think I have found various problems in the synchronization and
queuing of event between xterm.c, keyboard.c, and xselect.c, but
fixing those problems don't fix this problem.

Unfortunately no.

        Jan D.

reply via email to

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