I posted this before, but got no reply, so I'm trying again.
Look at this code, where I've added some timing code:
void GuiSelection::haveSelection(bool own)
{
QTime t;
t.start();
if (!qApp->clipboard()->supportsSelection())
return;
lyxerr << t.restart() << "msec check" << std::endl;
// Tell qt that we have a selection by setting a dummy selection.
// We don't use the interface provided by Qt for setting the
// selection for performance reasons (see documentation of
// Selection::put()). Instead we only tell here that we have a
// selection by setting the selection to the empty string.
// The real selection is set in GuiApplication::x11EventFilter when
// an application actually requests it.
// This way calling Selection::have() is cheap and we can do it as
// often as we want.
if (own)
qApp->clipboard()->setText(emp, QClipboard::Selection);
lyxerr << t.restart() << "msec call" << std::endl;
// We don't need to do anything if own = false, as this case is
// handled by QT.
// FIXME (gb): This is wrong. What is missing here is rather a call of
//else
// qApp->clipboard()->clear(QClipboard::Selection);
// Since we do not issue this call we rather implement
// "persistent selections" as far as X is concerned.
}
If you change the code as I have and select some text with, say,
Shift-Down Arrow, and watch the times, the call
qApp->clipboard()->setText(emp, QClipboard::Selection);
can take as long as 125ms on one of my machines (roughly a 2GHz Athlon).
That is ridiculous. What is particularly odd is that, how long it takes
depends upon whether the selection is within a single paragraph or
across a couple paragraphs. This is puzzling, since the actual call
never changes, but the time spent reliably does.
In any event, it seems that the comment about how cheap this call will
be is just wrong. I'm guessing there has to be a signal somewhere that
is causing the slowness. Any ideas?
Richard
