Hi Angus,
Angus Leeming wrote:
> No, I thought you said that you posted it for examination only?
It is in a working state. I meant the obvious: is not for applying to cvs
(said mostly to cover my back with dignity if you rejected it in disgust :)
>> If you scroll fast, then all insets not loaded
>> yet will go down the queue, replaced by newly touched ones.
>> And you don't need to check for visibility.
>
> I understand how it works. Nothing can be added to the queue whilst
> loadNext is running.
This is a threads limitation (in order to avoid clashes while accesing the
same data). What I plan to do is to reduce to a minimum (the time to copy
the data) the locking time, and make touch() to wait until unlocked.
> However, I also disagree with your last statement above. I think it
> would be 'better' is loadNext itself did what checkedLoading does
> now; there really is no need at all to start loading/converting
> graphics files that aren't going to be visible.
(Retreating ashamed) It's mostly why I've started coding this: to avoid
waiting for the previews to appear, (using idle time, i.e. without loading
all them at startup). If this not desired, then I don't see a real reason
for changing what there is now. It's working as intended, after all.
>
>> Sorry , failed completely to explain myself. What I wanted to say
>> is: can we
>>
>> 1) Make avery redraw to redraw more than one screen (say 1
>> fullscreen up and down) to refresh.
>> 2) Maybe call a redraw at startup after the full draw (so to 'touch'
>> the first screenfull of insets)
>
> Sorry, I still don't understand. I also don't know very much about
> how the stuff deep inside the 'LyX event loop' works.
Clearly neither do I. But when we scroll, startLoading gets called for newly
visible insets (probably because draw() was called for these insets?). I
would want it to be called for a screenfull up and down also.
> if (!running())
> startTimer();
>
> is no overhead worth talking about.
You are right.
> I can happily concieve of a long document with graphics at the end.
> Why would I need to start a timer if I'm editing at the top of the
> document?
Well, see above. I _do_ think it's desirable if there are graphics on the
document. And if you are talking about the overhead of the timer while
there is no graphics at all, I think it's negligible.
> LyX used up to LyX 1.1.6. He then dissappeared. I tried to get his
> code working for LyX 1.2. The result was a nasty mish mash (my fault
> not Baruch's). It was also very limited. André started playing with
> David Kastrup's latex-preview idea and was almost sick when he delved
> into the LyX graphics code. It was very hard to extend too, so, my
> embarrassment forced me to re-write it. He was very kind and
> gave me lots of tips about how to 'think' clean code.
>
> So, call André the wizard and call me his apprentice, Mickey Mouse.
Come on! So you are both wizards.
> We have a nice ForkedCall class that emits a signal when the forked
> process ends. We could have a function processQueue() that pops a
> single item off the queue and forks a process with it. When it
> finishes, the ForkedCall emits a signal which LyX uses to start the
> loading process. This loading process could also call processQueue()
> to pop another item off the queue.
Got it, thanks.
> Alternatively processQueue could write a little shell-script wrapper
> of all processes in the queue and fork this 'über script'.
>
> The former idea, although a little more complex has the advantage
> that we could load images as they become available rather than after
> ALL have been converted.
Indeed.
Bye,
Alfredo
