Salutations!
However, as for diagonal scrolling, I had an impression that the existing code in sp_canvas_paint_rect already addresses this:
[snip]
So, can you please provide more details on your approach?
Actually, the problem is earlier. A diagonal expose event dirties a L-shaped region of tiles. Then, in
2036 static int 2037 paint (SPCanvas *canvas) 2038 {
we have
2060 if ( canvas->tiles[tile_index] ) { // if this tile is dirtied (nonzero) 2061 dirty = true; 2062 // make (pl..pr)x(pt..pb) the minimal rect covering all dirtied tiles 2063 if ( i < pl ) pl = i; 2064 if ( i+1 > pr ) pr = i+1; 2065 if ( j < pt ) pt = j; 2066 if ( j+1 > pb ) pb = j+1; 2067 }
which forces a full-screen redraw. My solution was to use a Gdk::Region to construct a better region for redraw.
I was also thinking of getting rid of canvas->redraw_aborted altogether, and just not "cleaning" the dirty tiles until the redraw actually happens. I think that this way, we will be prepared for simultaneous dirty/redraw events. (My work so far doesn't do that yet -- it does the rendering in parallel, but blocks the main thread.)
Alternatively, we can upgrade (and probably rename) the canvas->redraw_aborted to a Gdk::Region (or a GdkRegion -- what's preferred?) and forget about the tiles. We will probably want to divide by TILE_SIZE to avoid redrawing 1-pixel areas.
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.
Ok. I was wondering if there was a going to be a massive rewrite to C++ or something.
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.
Yeah, the odd thing is that the sp-canvas seems to hold only 3 items -- one is the canvas-arena with everything else and there are two SPCtrlRects. This seems like a bit of duplication of effort. (This doesn't bother me right now, but we should probably merge the two sometime before/during when we allow scene to change while we are rendering.)
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.
Cool, I'll definitely package up everything I've done by Friday, and we'll see how busy school gets ;-)
Dennis Lin
On 8/14/07, Dennis J Lin <djlin@...1229...> wrote:
Actually, the problem is earlier. A diagonal expose event dirties a L-shaped region of tiles. Then, in
2036 static int 2037 paint (SPCanvas *canvas) 2038 {
we have
2060 if ( canvas->tiles[tile_index] ) { // if this tile is dirtied (nonzero) 2061 dirty = true; 2062 // make (pl..pr)x(pt..pb) the minimal rect covering all dirtied tiles 2063 if ( i < pl ) pl = i; 2064 if ( i+1 > pr ) pr = i+1; 2065 if ( j < pt ) pt = j; 2066 if ( j+1 > pb ) pb = j+1; 2067 }
which forces a full-screen redraw. My solution was to use a Gdk::Region to construct a better region for redraw.
I see. So in other words, when the two perpendicular narrow rects are exposed in two different events (e.g. first scrolling a bit vertically and then horizontally) then the existing code in sp_canvas_paint_rect takes care of that. But if they are exposed in a single event (scrolling diagonally), then that will fail because the tiles code in paint() will just lump that into a whole-screen rect at once. That is certainly a valid concern and I'll be happy to review your patch fixing this.
I was also thinking of getting rid of canvas->redraw_aborted altogether, and just not "cleaning" the dirty tiles until the redraw actually happens.
That would be nice too - if you indeed can generate minimal regions from any configuration of dirtied tiles, and if you can ensure that a tile is undirtied as soon as it's drawn, then the redraw_aborted rect is indeed unnecessary.
Alternatively, we can upgrade (and probably rename) the canvas->redraw_aborted to a Gdk::Region (or a GdkRegion -- what's preferred?) and forget about the tiles. We will probably want to divide by TILE_SIZE to avoid redrawing 1-pixel areas.
Yes, that's possible too, just another approach with the mostly same end result.
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.
Yeah, the odd thing is that the sp-canvas seems to hold only 3 items -- one is the canvas-arena with everything else and there are two SPCtrlRects. This seems like a bit of duplication of effort.
Well, but all that tiles and rects logic needs to live somewhere - I think it's nice that we have an entire layer of hierarchy (canvas) devoted to these issues.
On Tue, 2007-08-14 at 14:40 -0500, Dennis J Lin wrote:
I was also thinking of getting rid of canvas->redraw_aborted altogether, and just not "cleaning" the dirty tiles until the redraw actually happens. I think that this way, we will be prepared for simultaneous dirty/redraw events. (My work so far doesn't do that yet -- it does the rendering in parallel, but blocks the main thread.)
I don't think we'll be able to unblock the main thread for the near future -- the renderer (NRArena) is poorly isolated and potentially reaches throughout all the subsystems (chiefly by way of SPStyle).
By the way -- something to keep in the back of your mind is that the NRArena* objects and buffers are managed by the boehm garbage collector. You *MUST* ensure that the threads created by TBB are created via the boehm collector's thread wrappers so that it can inspect their stacks.
-mental
participants (3)
-
bulia byak -
Dennis J Lin -
MenTaLguY