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