Joao B. Oliveira wrote: > > Hi everyone (specially the folks from the devel team),
Hello, Joao.
> Some history first: I keep LyX running on a Computer Science
> Department, with some 20-30 students constantly using LyX on several
> machines. Everything was fine, until LyX 1.2.0 came along. The
> problem was, the handling of figures was changed in that version,
> and from that version onwards the students that work on documents
> with a larger number of figures (or larger figures) were horrified
> to see that their documents were taking like 10 minutes (sometimes
> much longer) to be opened, and the convert processes would take
> over the machine. Simply opening a document and scrolling down
> to the editing point would create so many conversions and take
> up so much memory that using the system is impossible. In fact,
> situation is so bad that I have already given up LyX myself, at
> least for documents that have more than a few images.
The image handling code in LyX 1.2 is indeed nasty. Things should be much
better in LyX 1.3. In LyX 1.3 the conversion process is triggered only for
images that have been on screen for 2 seconds, so you should now be able to
scroll without any conversion occurring.
> Our machines are neither small nor slow, and LyX (currently 1.3.0)
> simply makes them stop with the conversion process.
I am surprised at this as I would expect only one or two images to be
converted at a time (since only one or two images will be visible on the
screen at any one time).
> So, I went after documentation or details but did not find anything
> that I could use to accelerate things. I really need to understand
> what is going on, and maybe someone can answer these questions (and
> ADD THEM to the current documentation):
That would be welcome.
> -- First of all, how does the conversion/display process really
> works? Specially, how EPS files are handled? (I understand that
> they are always converted to ppm for displaying? Why ppm?)
If you run
$ lyx -dbg graphics
you'll see that the conversion is handled by an external program. You can
specify the program you use by defining formats and converters between
formats. See the Edit->Preferences dialog.
By default, we use ImageMagick's 'convert' program, run through a script
convertDefault.sh. I too find that 'convert' is very slow. (But this
shouldn't really matter. See above.)
I attach a modified convertDefault.sh that uses ghostscript to convert eps
files to either ppm or png format. Personally, I would use it as the basis
for a my_ps2ppm or my_ps2png converter...
As for the final format, well we chose ppm because both the xforms and Qt
frontends can load it natively. If you are using the Qt frontned, then I
suggest that you define a converter ps -> png.
> -- In previous versions EPS files could be displayed rather
> quickly. Why was their processing slower from 1.2.0 on?
Because the code was rewritten from scratch to be more flexible. The old
code had its own bugs and was unmaintainable.
> -- Is there a way of avoiding the conversion process and handling
> EPS files directly?
Possibly. It depends on the image loading abilities of the underlying GUI
toolkit. The xforms library most certainly CANNOT handle arbitrary
PostScript files reliably, so native loading of PostScript files is
disabled in the xforms frontend. I don't know about the abilities of the Qt
loader. Try modifying the loadableFormats method in
src/frontends/qt2/QLImage.C.
> -- Is there a way of accelerating the conversion process (if it
> cannot be avoided)? Are there shortcuts to be used?
Try using a converter other than ImageMagick's convert. See attached.
> -- When several images are in the same figure, they *all* get
> converted at the same time, filling up memory and swap space.
> At the very least, can this be changed so that we get one conversion
> at a time, to preserver swap space (and time, as a consequence?)
>
> -- If EPS files are large (I have some with more or less 1.5 Mb)
> their conversion and displaying takes all memory and a 64Mb computer
> simply crashes. With more images of the same size, larger machines
> crash as well. Was this foreseen?
Of course not. Feel free to add you expertise to the development effort.
> I would appreciate any help, as I want to keep LyX running but
> currently I also have to explain many things to both management
> and disappointed students.
Let us know if any of this information helps...
--
Angus
convertDefault.sh
Description: application/shellscript
