Salutations!
My name is Dennis Lin, and (until Friday) I'm an intern at Intel. As you may have heard, Intel has released a GPL version of Thread Building Blocks (http://osstbb.intel.com/). In an attempt to gain greater adoption, they have asked me to look into using it to thread existing open-source applications.
I've played with the Inkscape source for the last couple of weeks, and I should have some patches soon. I'll try to put out a patch later today to avoid redrawing the entire screen when scrolling diagonally. (This should be independent of scrolling). Where do you prefer your patches?
I also have some questions as to how I should proceed. I have found (the hard way) that nr-arena-shape is very *not* threadsafe. However, the Cairo version seems to be a lot better. Is the intent to move everything to Cario in the near future? (I probably don't have enough time remaining to do the conversion, but I might be able to get started, and I can continue on my "free time" after school starts again.) More generally, I have noticed that the sp-canvas and nr-arena-item seem to be scheduled for a rewrite. I have been trying to keep my changes relatively unintrusive, but I was wondering what direction I should be trying to nudge things.
Finally, I would like to gauge the interest in this work. What are your sentiments on multithreading in general, and in using TBB to do in particular?
Thank you for your time,
Dennis Lin
On Tue, Aug 14, 2007 at 01:37:55PM -0500, Dennis J Lin wrote:
Salutations!
My name is Dennis Lin, and (until Friday) I'm an intern at Intel. As you may have heard, Intel has released a GPL version of Thread Building Blocks (http://osstbb.intel.com/). In an attempt to gain greater adoption, they have asked me to look into using it to thread existing open-source applications.
I've played with the Inkscape source for the last couple of weeks, and I should have some patches soon. I'll try to put out a patch later today to avoid redrawing the entire screen when scrolling diagonally. (This should be independent of scrolling). Where do you prefer your patches?
There is a patch tracker we encourage people to use for posting patches.
Our policy for SVN access is, once you've had two patches accepted you can request SVN access by just sending me or one of the other admins your sourceforge username.
Some people like to work on experimental changes on a branch, others prefer keeping everything in the main head so it gets adequate review and maintenance.
I also have some questions as to how I should proceed. I have found (the hard way) that nr-arena-shape is very *not* threadsafe. However, the Cairo version seems to be a lot better. Is the intent to move everything to Cario in the near future? (I probably don't have enough time remaining to do the conversion, but I might be able to get started, and I can continue on my "free time" after school starts again.) More generally, I have noticed that the sp-canvas and nr-arena-item seem to be scheduled for a rewrite. I have been trying to keep my changes relatively unintrusive, but I was wondering what direction I should be trying to nudge things.
Yes, the intent is to move to Cairo in the future, however there's some work still needed before that can be done. Bulia has looked at this the most and can probably best explain what tasks remain.
I think there are other areas that are very non-threadsafe. IIRC, this was discussed in depth at least once or twice on the inkscape-devel@ list, so you might find it of value to search out those threads. Mental and Ted would probably give the best explanation of the current status for that.
Bryce
On Tue, 2007-08-14 at 11:56 -0700, Bryce Harrington wrote:
I think there are other areas that are very non-threadsafe. IIRC, this was discussed in depth at least once or twice on the inkscape-devel@ list, so you might find it of value to search out those threads. Mental and Ted would probably give the best explanation of the current status for that.
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.
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 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.
I keep thinking I should buy that TBB O'Reilly book, guess it's time :)
--Ted
On 8/14/07, Dennis J Lin <djlin@...1229...> wrote:
I've played with the Inkscape source for the last couple of weeks, and I should have some patches soon. I'll try to put out a patch later today to avoid redrawing the entire screen when scrolling diagonally. (This should be independent of scrolling). Where do you prefer your patches?
Thanks, that's very interesting! Please submit your patch to our patch tracker.
However, as for diagonal scrolling, I had an impression that the existing code in sp_canvas_paint_rect already addresses this:
1856 // If the summary area of the two rects is significantly (at least by 20%) less than 1857 // the area of their rectangular union, it makes sense to paint the two rects 1858 // separately instead of painting their union. This gives a significant speedup when, 1859 // for example, your current canvas is almost painted, with only a strip at bottom 1860 // left, and at that moment you abort it by scrolling down which reveals a new strip at 1861 // the top. Straightforward painting of the union of the aborted rect and the new rect 1862 // will have to repaint the entire canvas! By contrast, the optimized approach below 1863 // paints the two narrow strips in order which is much faster.
So, can you please provide more details on your approach?
I also have some questions as to how I should proceed. I have found (the hard way) that nr-arena-shape is very *not* threadsafe. However, the Cairo version seems to be a lot better. Is the intent to move everything to Cario in the near future?
Yes. Certainly. However, as planned now, the move to cairo will not get rid of nr-arena-shape. We plan to just remove the rendering calls to livarot methods and reduce the lots of extra buffers that are now created and then composed. Instead we'll just use cairo calls to draw shapes in a single buffer. See the outline mode which is now drawn entirely by cairo - the regular mode will be similar except a lot more code will be needed to translate gradients, patterns, etc. to cairo format.
Right now cairo conversion is on hold until several cairo bugs are fixed.
More generally, I have noticed that the sp-canvas and nr-arena-item seem to be scheduled for a rewrite. I have been trying to keep my changes relatively unintrusive, but I was wondering what direction I should be trying to nudge things.
I don't think they realistically will be rewritten in the near future. At least sp-canvas seems to be more or less adequate for our needs, with or without cairo.
Finally, I would like to gauge the interest in this work. What are your sentiments on multithreading in general, and in using TBB to do in particular?
We know we're in a rather bad shape with regard to multithreading :) But there's certainly a lot of interest for exploring what can still be done to improve the situation.
participants (4)
-
Bryce Harrington
-
bulia byak
-
Dennis J Lin
-
Ted Gould