Alfredo Braunstein wrote: >> 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?
Yes. That's why we have to have this "see if the inset is visible" check (uses GraphicsSupport's isInsetVisible.) The two second pause between the call to Inset::draw and Loader::Impl::checkedLoading() allows the user to scroll past graphics insets without triggering a load unnecessarily. Only when the thing is visible for a finite period is loading started. > 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. That's essentially what we do now, although your terminology is a little different. >> Where/who would call loadNext? > loadNext is the threaded part, it's called automatically every .1 > seconds. Oh yes. I see. It might be nice to have an explicit LoaderQueue::startLoader so that the thing is only started with the first attempt to 'touch' something. >> 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. Me neither. Hence the desire for feedback. >> 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? I think that the GraphicsConverter generates a shell script wrapper for each conversion process. It also executes these scripts. I think that we could change things only slightly by getting it to create the scripts as it does now and putting the execute command on a queue to be executed sequentially. You see? You've forced me to think and the answer just 'came'. Thank you. > Thank Angus. > Bye, Alfredo Tara! -- Angus
