Abdelrazak Younes wrote:

Andre Poenitz a écrit :

On Mon, Feb 06, 2006 at 09:59:42AM +0100, Jean-Marc Lasgouttes wrote:

"Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:

Helge> I tested the userguide, no problems there. Further testing
Helge> shows that it is related to images. I have some high resolution
Helge> images - of course I expect those to be slow. But the slowness
Helge> happen even in cases where images aren't on screen. Typical
Helge> case:

This is what I was about to suggest: currently, every time a paragraph
is created/killed, the whole document after it is duplicated. For
images, this means a lot of work. In particular, I think a pixmap is
created in the X server, which means a lot of data to transfer.


We should try Abdel's 'transparent vector of pointers' approach soonish.


This is the signal I was waiting for... ;-)
I have implemented this approach yesterday evening. The gain in responsiveness when inserting or removing paragraphs is not fantastic but it is sensible. _But_, my debug info tells me that those actions are _immediate_ now, whereas they were not with the classic vector<Paragraph> approach. So I think there is another bottleneck elsewhere. I have put convenience function so as to minimize the changes needed in the code that uses ParagraphList. But there are some minimal (IMHO) change. The interface is simpler so a lot of code could be simplified with this new class.

Anyway, please find attached the patch. Everything but CutAndPaste (which crashes lyx) seems to work OK. But I didn't do extensive testing... sorry about that. If this is interesting to you, I'll try to find some time this week-end to refine the approach.

I see that Helge Hafting has created bug 2287 for that so Helge, maybe you could attach this patch to this bug? And maybe test if there is any improvement with your use case?

This patch helps a lot, although there is one slow case left.
I opened my document, over the net, and scrolled through it to make sure all
the images was loaded. Splitting paragraphs in the beginning generally work well. The delay is gone from most of the paragraph-splitting cases, very good! The remaining slow cases are: * Split a bullet list item, when some later bullet in that list contains an image.
 Curiously enough, re-merging these entries (by backspacing over the
 paragraph split) is fast.  It is only the split that is slow.
* Split the paragraph containing an image. (Possibly the same as the previous
 one, for it was also a bullet-list entry.

Splitting bullet paragraphs after the last image in a list is ok, and so is
splitting bullet paragraphs in lists that don't have images.

I also discovered another slow case, which exist in standard lyx as well:
Sometimes, simply adding text to the end of a bullet paragraph that
have an image, will be slow.  20s to add an "a" after the image,
the image was the previous last position of that paragraph.  Something
went wrong, the delay was even worse than the usual paragraph splitting delay,
the network was busy all that time.

Helge Hafting

Reply via email to