Andre Poenitz <[EMAIL PROTECTED]> writes: > > > At the current point of time, preview-latex is defensive in > > resource usage; you need an explicit request to let it start the > > background machinations. Part of the reason is that there are > > associated fixed costs with starting up LaTeX, DviPS and > > GhostScript, and one would want to group requests as much as > > possible. > > I see. So there _is_ a performance problem.
It is called Jan-Åke. He has a 150Mhz computer or so. At the current point of time, preview-latex is working convincingly for him, but this has not always been that way. Historically, DviPS was called with options -i -E in order to generate one EPS file per image. Generating the stuff separately took time, passing it through GhostScript (which reloaded fonts and reinitialized sections all the time) took time. EPS was necessary because of bounding boxes. We now get the bounding box info from directly from TeX. This necessitated quite a few changes in preview.sty: previously it was fine with outputting horizontal material in a \vbox as a full line: DviPS determined the bounding box just by looking at actually typeset material. Cropping the boxes to sensible dimensions from TeX requires quite a bit of wizardry with \lastbox, \vsplit and the like. Since we now have the bounding box info available separately, we don't need no stinking EPS, but just a single fat PS file. Its preamble is just passed once through GhostScript, then the separate pages are passed in display optimized order through. This necessitates some basic parsing of the DSC comments, like PostScript previewers do. By now one could probably make some of the reprocessing automatic. > > LaTeX startup time can be considerably reduced by dumping formats > > (the CVS version of preview-latex uses Carlisle's mylatex.ltx for > > that purpose). The ultimate goal would be to keep one pipe > > running. DviPS cannot really be made to fit into that scheme, one > > would probably want to ultimately replace it with a DVI to bitmap > > rendering daemon. GhostScript could probably be kept running > > efficiently across multiple DviPS runs if you did clever resource > > management (do not download already present fonts and other stuff > > etc). But that's all future stuff to think about. > > Do you think you (or somebody else for that matter) will do that > kind of work? "Soonish"? There is the GPLed DVIlib2 library rendering DVI directly to bitmaps. That would be just the thing to use. Unfortunately, in some experiments I did it appeared to be slower than the DviPS/GhostScript combo. It also had some other problems (like not wanting to render above the 0in coordinate even if I told it the paper was supposed to start above there). I have not received replies to some requests to the author, and have not pursued this matter further. If people were willing to invest serious work into it, this would probably be the technically soundest implementation path in the long term. There is a dvi2bitmap program under a noncommercial license (which is not really good enough for me to want to make my GPLed code rely on it), and there is presumably some free dvi2gif that could be slaughtered for its innards (the latter info I just recently got from Yannis Haralambous). It might also be an idea to take a look at a few DVI previewers (traditionally fast renderers of bitmaps) and see whether one could rip code from them. But the DviPS/GhostScript path is a good start and should probably be retained at least as an option for things like PStricks graphics. > > > I'd basically need a _fast_ way to get some rendered bitmap out of a > > > string like $a^2+b^2$. That's it. The "obvious" solution would be to > > > create some temp.tex, run LaTeX on it, convert the dvi. I don't know > > > how 'fast' this is, though. > > > > If you start with a pregenerated format, surprisingly so. But you want > > to have this work asynchronously: editing should not block actively while > > the rendered bitmaps trundle in. > > Sure.... we could just keep a list of "insets to be rendered" in a > background process and as soon as one is finished, we cache this in the LyX > inset and display it when needed (i.e. when the next redraw request comes) > instead of doing our "homegrown rendering". Good. > > [...] The problem was that Emacs rendered on-demand. Scroll to a page > > with 20 previews on them, and Emacs started 20 GhostScript processes and > > would block until most of them were finished placing their bitmaps right > > into the window. > > Doing that without blocking should be possible in LyX... Don't ever think of starting 20 GhostScript processes simultaneously for 20 previews. It's sinful. > > This is quite important for its acceptance: does > > LyX offer some sort of multithreading or asynchronicity or the like? > > We don't have proper multithreading, but some of the graphics stuff is > (was?) rendered asynchronously already. That sounds like the basic framework should be there. Emacs does not have proper multithreading either, but that does not seem to impact operation noticeably. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
