Angus Leeming wrote:
> Ok, so:
> std::queue tmp;
> swap(bucket1_, tmp;
> Still no need to pollute the class interface...
You are right (as always). Done, thanks.
I'll try to send something to the list this evening. Right now I need to get
some real life work done...
In the meant
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> There is still no need to have bucket2_ as a class member...
>>
>> void LoaderQueue::emptyBucket()
>> {
>> cout << "emptying bucket" << endl;
>> std::queue tmp = bucket1_;
>> while (!tmp.empty()) {
>> a
Angus Leeming wrote:
> There is still no need to have bucket2_ as a class member...
>
> void LoaderQueue::emptyBucket()
> {
> cout << "emptying bucket" << endl;
> std::queue tmp = bucket1_;
> while (!tmp.empty()) {
> addToQueue(tmp.front());
>
Andre Poenitz wrote:
> On Thu, Feb 20, 2003 at 02:15:06PM +0100, Alfredo Braunstein wrote:
>> > It doesn't depend on BufferView. Why not make it a singleton class?
>>
>> Sure... what's a singleton class?
>
> Just put it into a class and create just one object of it.
> [The rest is rather ideolog
Alfredo Braunstein wrote:
>> exit to the method. In fact why not:
>> +void LoaderQueue::emptyBucket()
>> +{
>> + cout << "emptying bucket" << endl;
>> + while (! bucket1_.empty()) {
>> + addToQueue(bucket1_.front());
>> + bucket1_.pop();
>> + }
>> +}
>
On Thu, Feb 20, 2003 at 02:15:06PM +0100, Alfredo Braunstein wrote:
> > It doesn't depend on BufferView. Why not make it a singleton class?
>
> Sure... what's a singleton class?
Just put it into a class and create just one object of it.
[The rest is rather ideology]
Andre'
--
Those who des
Angus Leeming wrote:
> It doesn't depend on BufferView. Why not make it a singleton class?
Sure... what's a singleton class?
> bucket1_ is filled with Cache::ItemPtrs to be dealt with by
> LoaderQueue::touch.
>
> The timer calls LoaderQueue::loadNext every 100 ms.
>
> LoaderQueue::loadNext cal
Alfredo Braunstein wrote:
> A second option for LoaderQueue.
> I've left the previous interface untouched, but changed a little the
> implementation. Now touch() doesn't add directly the image pointer to the
> queue, but it adds it to an input bucket (implemented as a plain queue)
> without any ch
Alfredo Braunstein wrote:
> PS: using previews with current cvs, I get a strange behaviour. In a new
> document, make a math inset (like... C-m 1 esc). Then Latex and dvipsk are
> called twice. Does anyone else see it? Is it intended? Why?
Yes I see it. No it's not. Don't know.
--
Angus
Angus Leeming wrote:
> Actually, after I wrote this, I think that your code is perfect as it
> is. No need for the isInsetVisible stuff or the 2 second pause at all.
>
> Moreover, if you modified GraphicsConverter as well so that it
> created a queue of scripts to execute sequentially, as describ
Alfredo Braunstein wrote:
>> 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
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 load
Andre Poenitz wrote:
> On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote:
>> So, call André the wizard and call me his apprentice, Mickey Mouse.
>
> And just to give some insight into what makes a wizard in Angus'
> eyes:
>
> One has to be too dumb to understand anything spanning mor
On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote:
> So, call André the wizard and call me his apprentice, Mickey Mouse.
And just to give some insight into what makes a wizard in Angus' eyes:
One has to be too dumb to understand anything spanning more than a
screenful of code or more
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>>> 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 Ins
Angus Leeming wrote:
>> 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::checkedL
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
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
>
Alfredo Braunstein wrote:
> I'm fiddling a little with the graphics loader, and I started to
> implement a pseudo threaded version of it (patch attached).
>
> It works as follows: there is this LoaderQueue class (I think every
> BufferView should have one, right now is simply a global class),
> w
Andre Poenitz wrote:
> On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
>> Right now it's implemented as a queue + a set, so it's O(ln n) for the
>> 'first time insert' case, and O(n) for the 'already have it' case.
>> I plan to make it O(ln n) always.
>
> Good idea, but we do
On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
> Right now it's implemented as a queue + a set, so it's O(ln n) for the
> 'first time insert' case, and O(n) for the 'already have it' case.
> I plan to make it O(ln n) always.
Good idea, but we do pretty expensive things in othe
21 matches
Mail list logo
