Bug 59772

Created attachment 73534 [details]
test document

Created attachment 73535 [details]
X11 clipboard test program

This is a simple test program that pastes data from the clipboard and writes it to standard out. It requires X11 libraries.

To get a list of targets:
$ ./readclipboard TARGETS

To paste a target from the above list:
$ ./readclipboard <name of target>

So I time the rtf conversion like this:
$ time ./readclipboard text/richtext >/dev/null

First, apologies that it took so long for QA team to get to this - our team is stretched thin but we're trying to tackle these triage jobs a bit faster.

Now, unfortunately I have to put this into INVALID status. There isn't much here for us to work with, saying "long time" isn't really a workable issue. Saying "I want conversion to be faster" isn't a valid bug report - it would be just as easy to say this is Wine's bug and saying "the 0.5 second time out is unworkable". 

Because of this, marking as INVALID. If you are 100% convinced this is a bug (and not just a "I want it faster") please do several tests:

1. Check to see if the paste is "slow" no matter what you paste to (ie. don't try pasting in a Windows emulator that is running Microsoft Office), try in a native Linux application

2. Give us some reason why (a programming reason, or comparing to some other software, something more than "I want faster") you think it's "too slow"

Apologies if this sounds a bit rough, just please keep in mind that we deal with thousands of bug reports.

The attached test program IS a native Linux application, and you can time it. But I can probably find something else if you don't trust that. Word on real Windows, or the "paste special" option on Abiword will probably do it.

I thought about trying to get Wine's timeout increased, but I think I came to the conclusion that the time scaled with the number of images, so increasing it wouldn't really solve the problem. Because of the way the Windows clipboard API works, it's not possible for Wine to stay responsive while pasting, so it needs the timeout to guard against the possibility that the program with the clipboard hangs or crashes while serving its request.

I don't consider this bug very important, since copying/pasting between LibreOffice and Word on Linux is an unusual thing to do. I mostly reported it here because we (codeweavers) had it in our bug tracker, and the only viable way to fix it seemed to be in this project.

I might also test how the time scales with the number of pixels in an image. Anything more than O(n) would demonstrate a programming problem.

Copying text and an image on Windows (to, for example, wordpad) will hang LibreOffice for the duration of the conversion, so it can be observed that way without involving Wine.

It does appear to be O(n), in that if I make a picture 3 times as large or copy 3 times as many images, it takes 3 times as long to convert.

The best argument I can find that something is wrong is that copying the image by itself is 10 times faster than copying text and the image. Writer copies images by themselves in BMP format, while in the RTF it writes hex-encoded JPEG data. Converting to JPEG and then encoding that to hex probably takes some time, but AFAICT there's no need for Writer to be doing this. Based on the RTF spec it seems entirely possible to use raw BMP data.

Word 2003 uses hex-encoded PNG data, and it seems to be about 4 times faster (but I can't measure it in quite the same way because it does the conversion immediately when the data is copied, and if it did not it would most likely trigger a similar bug).

So, maybe most of the time is taken by the encode to JPEG, but I would argue that for clipboard operations you should choose a method that is fast at the cost of compression. Maybe BMP is too large, but I can't think of a reason it would be good enough for copying images on their own and not images in rtf.