On Mon, Nov 19, Johannes Hofmann wrote:
Hi Sebastian,
this patch is obsolete, as fltk does all that for us: The void Widget::redraw(const Rectangle& r) method marks a rectangle for later redraw. See my followup mail for a much shorter patch that does the same thing. It's already in cvs.
I will try to summarize how fltk handles redraws (as I have understood it so far):
* Redraw requests from the program itself or from the outside (expose events) are accumulated by fltk and will result in a later call to the draw() methods of the various widgets. Information about what is to be drawn is passed via a bitmap that can be accessed using Widget::damage() and via the current clipping region.
* A program can require redraws using void Widget::redraw(const Rectangle& r). In this case fltk ensures, that r will not be clipped during a subsequent draw().
* A program can require redraws using void Widget::redraw(uchar c). In this case fltk ensures, that at least the bits that are on in c will be turned on in the damage() bitmap during a subsequent draw().
This is actually a bit more complicated, as I remember. A widget redraw is referred in canvas coordinates, but FLTK referres to viewport coordinates. I once described this in a mail (unfortunately not in the code), which I cannot find now, so here again an example: 1. A widget requests a redraw for the canvas region (100, 100, 100 x 100) [x, y, w x h]. If the viewport position is at (50, 50), this is translated to (50, 50, 100 x 100). Notice, that the drawing is not done immediately at this time. 2. The viewport is scrolled to (50, 100) (i.e. scrolled down 50px). 3. Now, the idle function is activated, and draws the region (50, 50, 100 x 100). This is, since the viewport position has changed, the canvas region (100, 150, 100 x 100). This means, that the upper half of the originally requestet *canvas* region is not drawn (it has been scrolled out of the original viewport region, so to speak). So, Dw (or the FLTK part of Dw) has to do some work on its own. See Dw_gtk_viewport_queue_draw in dw_gtk_viewport.c (old code) for details. I'm not currently aware of all implications of it, I'll have to take another deeper look at the old code. Sebastian