Angus Leeming wrote: Hi Angus, thanks for the answers.
> I can answer that. Three classes are interested in graphics. > insets/insetgraphics.C together with mathed/formula.C and > insets/insetinclude.C for the previews. These latter two have > instances of a class PreviewImpl that derives from > grfx::PreviewedInset. InsetGraphics has an instance of a Cache class. > > In all cases the loading of the image is triggered by the Inset's > draw() method. Eg InsetGraphics::draw has > if (cache_->loader.status() == grfx::WaitingToLoad) > cache_->loader.startLoading(*this, *bv); I see. But draw() is called for all insets at startup time, right? All the document is drawn at startup, even if it's not visible. I'm asking this because I think the optimum would be to 'refresh' i.e. touch() all WaitingToLoad grafics near the cursor (up and down) at every time. Or something like that. > We're always nice ;-) Seriously, this is very clever of you and Im blushing. > surprisingly non-invasive. Where/who would call loadNext? loadNext is the threaded part, it's called automatically every .1 seconds. > Did you find the graphics code understandable or did you find it to > be a convoluted mess? What could be done to improve the architecture? I think it's nice. Of course it's not simple, but neither it's task is. I still have some problems understanding some parts. I will get to specific questions soon. You are asking _me_ hoy to improve it? I'm blushing again. Never programmed a graphics loading mechanism before. Let me get used to it, and I will tell you. What are the problems in it, apart from the 'convoluted' code? (I think part of the convolution will go if we make it threaded... this 2 secs call back for instance) > I have a question/suggestion for you myself. (Thinking out loud > really.) Do you think it would be easy to split the "conversion to > loadable format" stuff out of grfx::CacheItem? > > At the moment we have one conversion process for each file to > convert, so several processes run in parallel (with possibly nasty > consequences on the system resources). It would be nice to gather > them together into a single script and launch that. What do you think? > I think it can be easily implemented with the 'threaded' paradigm as the image loading (even maybe together?). That's it: you request some conversion, it is added to some queue, and done when time comes, sequentially (by the threaded part). What do you think? Thank Angus. Bye, Alfredo
