Hi Jorge, On Sun, Feb 03, 2008 at 02:53:59PM -0300, Jorge Arellano Cid wrote:
Hi Johannes,
On Sun, Feb 03, 2008 at 06:06:39PM +0100, Johannes Hofmann wrote:
Hi,
the following patch fixes the problem here:
diff -r 4a9e0384d5ca dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Sat Feb 02 18:35:17 2008 +0100 +++ b/dw/fltkviewbase.cc Sun Feb 03 17:59:04 2008 +0100 @@ -64,7 +64,12 @@ void FltkViewBase::draw () translateCanvasYToViewY (rect->y), rect->width, rect->height);
- viewRect.intersect(view); + viewRect.intersect (view); + + rect->x = translateViewXToCanvasX (viewRect.x ()); + rect->y = translateViewYToCanvasY (viewRect.y ()); + rect->width = viewRect.w (); + rect->height = viewRect.h ();
if (!viewRect.empty ()) { push_clip (viewRect);
It uses the rectangle that has been intersected with the current view area for expose().
Great!
BTW, I have also found places where an intersection may be missing...
But the real bug seems to be hidden somewhere in the table draw code. Without the patch, expose was called with a very high area (height was 106497!).
Please try to get to the root of the problem. I'll keep on the too-many-redraws problem. Later we can merge the ideas.
The root cause seems to be an overflow of X11 coordinates. If you try: #include <stdio.h> #include <fltk/Window.h> #include <fltk/Widget.h> #include <fltk/Button.h> #include <fltk/run.h> #include <fltk/draw.h> #include <fltk/damage.h> using namespace fltk; Widget *test; class Test : public Widget { public: Test(int _x, int _y, int _w, int _h) : Widget(_x, _y, _w, _h) {}; void draw() { for (int y=1000;y < 70000; y +=10) { fillrect(0, y, 10, 10); } } }; int main(int argc, char **argv) { Window *window = new Window(300, 180); window->begin(); test = new Test(20, 40, 260, 100); window->end(); window->show(argc, argv); return run(); } you will see a black bar. If you only count to 60000 instead of 70000, the window stays gray. X11 uses shorts somewhere that can overflow. So the fix in fltkviewbase.cc is sufficient, I think. Cheers, Johannes
This seems to cause problems. Perhaps some overflowing values? With the patch (which is a good optimization anyway), the height of the area that is passed to expose is limited by the current view size.
OK.
It looks like there's no problem to commit this patch. I mean it doesn't hide the other bug, right?
-- Cheers Jorge.-
_______________________________________________ Dillo-dev mailing list Dillo-dev@dillo.org http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev