On Mon, 10 Jan 2011 21:19:35 +0100
Pavel Sanda <[email protected]> wrote:
> Michal wrote:
> > Unfortunately, in this case the stupid code would also be very
> > slow,
> why does it hurt when we do it in background invisible to users?
Well, it is invisible only when you have multicore cpu and fast hdd,
and that's assuming other programs aren't working in the background,
also trying to be invisible :)
> > The bisection isn't *that* smart anyway :). Just look at the
> it has log(n) only because you stop after first problem and do not
> let other insets to be rendered, which is not win when you err
> in the very beginning of the document.
I consider this a win because LyX then lets the user know where it
failed. At least wrt the current behavior, where nothing gets generated
anyway and the user does not know what's happening.
The user usually knows what's inside his/her own document,
so I suppose the fix for the pointed inset would usually be fast.
Also, there would be nothing wrong with LyX trying to re-render all
the other previews in the meantime, also using bisection. But this time,
if it fails, LyX should give up completely (and wait for corrections
from the user), to not to stole further cpu cycles. But that's just my
opinion.
> the problem typically is not that some formula is written badly, but
> because some package is missing on your system... all other insets
> could be rendered without problems otherwise.
I'm not sure if I understand you. Why do you assume such thing for
all the other insets? I can imagine a big document with a lot of preview
insets with the code inside using some package. Then, without this
package all the previews will fail. Not that unprobable, especially for
single-theme-oriented documents (is that correct English? :) ). BTW I
happen to have a lot of such documents, mostly using pgf/tikz-related
stuff.
ANYWAY, for now I am curious whether deferring all of this to dvips
-i (as Enrico Forestieri recently suggested) will speed things up, to
the point of obsoleting all the other ideas. But this solution also
assumes something: that the dvi file gets created at all. Wouldn't
a missing package prevent this?
Regards,
Michał Skrzypek
