Salutations!

(Sorry if the threading is wrong, I'm working with a webmail client right now.)

I think the current status is that we're not very thread safe :) I guess my concern is that probably the first step for us isn't implementing TBB. The first step is getting everything cleaned up so that implementing TBB is a reasonable next step.

I agree with you, but I wanted to have something to show, so I decided to tackle the rendering portion (which can take several seconds for a heavily filtered image like car.svgz.) So right now, I have a version that can render to different regions of the screen at the same time (there are locks protecting nr-arena-shape, so there is potential contention.)

As far as TBB itself goes, is it in any distros? How does it work with the whole Glib main loop? Perhaps implementing TBB in GTKmm is a good first step?

It might be interesting to incorporate TBB with libsigc++, so that signals can be processed in parallel. Actually, that was what I was thinking about doing when I happened upon Inkscape.

It seems to be one of the trickiest parts, in that we would like to have the GTK+ GUI responsive while processing is occurring as it would probably be the biggest perceived gain for users -- but is likely the most complex part. I think this ties directly into the issues the guys and Grinnel are seeing.

Yeah, I think that eventually I'm going to run into similar issues. For right now, however, I'm just reading the tree (during the idle timer event), so I don't have to worry about updates. As for the future, I think I can have aborted redraws working today or tomorrow (so that the system isn't *less* responsive). Maybe I can get it to the point that we can scroll and redraw at the same time before Friday. Anything fancier, however, is going to require a bunch of careful refactoring...

Dennis Lin