On 15 sept. 2010, at 11:25, Tudor Girba wrote:
> I know about this problem. As I understand it goes like this: the custom task somehow spawns another process besides the rendering, and thus the rendering needs the result.
ok one workaround for now it to put heavy computation in cache before opening a browser (in the case we are working on, it has to done this way anyway)
>
> I do not quite know how to solve this one, but I think we can solve it with the same effort of adding parallelized rendering in Glamour:
>
http://code.google.com/p/moose-technology/issues/detail?id=218Not sure I have a lot of time these days, but where to start? In GLMRenderer?
>
> It would cool to get some help.
>
> Cheers,
> Doru
>
>
> On 14 Sep 2010, at 17:38, Simon Denier wrote:
>
>> Hi
>>
>> It seems I have some problems to mix progress bars (using MooseCustomTask) and Glamour browser (it's related to Arki more precisely).
>>
>> I mean, I select some items in a browser, which then compute lazily their state. Some long computations are done in a Moose custom task to give feedback. But it gives errors or incorrect results in Glamour/Arki when it is done this way, generally because some data are incomplete when the browser is rendering the widget.
>>
>> I'm puzzled by how this happens, because it seems it should be managed by the UI thread.
>>
>>
>> Any hacker willing to take a look at Esug?
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>>
[hidden email]
>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
> --
> www.tudorgirba.com
>
> "Every thing should have the right to be different."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
>
[hidden email]
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev--
Simon
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Locked
