jody at gnome.org
Mon Dec 1 18:47:29 EET 2003
On Mon, Dec 01, 2003 at 03:48:12PM +0100, Lubos Lunak wrote:
> This means the only potentionally expensive part should be the actual
> transferring of the data. It should happen relatively rarely, usually with
> small amounts of data. Problems with large data can be handled by having a
> limit (hence the max selection size proposal), and also Klipper transferring
> only the data types it's interested in.
> If I open here 1MB file in KWrite or gedit, after doing Ctrl+A, Ctrl+C
> there's one short time of high CPU usage caused by it (<1s, this is Athlon
> 1600+ running X locally). Not that good, but I find it acceptable. And
> moreover I consider this to be a rare case - people usually put much smaller
> data in clipboard.
Why bother transfering just text ? That makes all the rich formats
Try that operation with kspread or Gnumeric. 1meg is trivial to
generate when you're spewing xml. Multiply that by a number of
supported formats and the amount of data gets large.
> IMHO the solution is sufficient, and has the best gain/effort ratio. The only
> complains about Klipper I remember are its CPU usage when the user selects
> very large data in the application, and this has been partially already fixed
> by the improved polling, and the maximum data size would take care of the
Toolkit support for notifying of impending exit so that the
clipboard could save all of the supported formats seems like a
stronger solution. Gnumeric has recevied alot of bug
reports/complaints when Klipper is enabled.
More information about the xdg