[patch] fix redraw problem with findText
Hello, the patch below fixes the redraw problem with findText found by place that was introduced with my textblock optimization. Partial redraws were interfering with scrolling. The findText method is a nice test for this code path! I'm now experimenting with a redraw optimization that covers table based pages too. It's looking promising, but it needs some more work. Cheers, Johannes diff --git a/dw/fltkviewbase.cc b/dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc +++ b/dw/fltkviewbase.cc @@ -85,6 +85,7 @@ void FltkViewBase::draw () } } + drawRegion.clear (); d &= ~DAMAGE_VALUE; } @@ -110,9 +111,12 @@ void FltkViewBase::draw () area.width = rect.w(); area.height = rect.h(); theLayout->expose (this, &area); + + if (! (d & DAMAGE_SCROLL)) { + drawRegion.clear (); + } } - drawRegion.clear (); } void FltkViewBase::drawChildWidgets () { diff --git a/dw/fltkviewport.cc b/dw/fltkviewport.cc --- a/dw/fltkviewport.cc +++ b/dw/fltkviewport.cc @@ -185,6 +185,7 @@ void FltkViewport::draw () int d = damage(); if (d & DAMAGE_SCROLL) { + set_damage (DAMAGE_SCROLL); scrollrect(cr, -scrollDX, -scrollDY, draw_area, this); d &= ~DAMAGE_SCROLL; set_damage (d);
On Sat, Feb 23, 2008 at 09:07:30PM +0100, Johannes Hofmann wrote:
Hello,
the patch below fixes the redraw problem with findText found by place that was introduced with my textblock optimization. Partial redraws were interfering with scrolling. The findText method is a nice test for this code path!
Good, committed.
I'm now experimenting with a redraw optimization that covers table based pages too. It's looking promising, but it needs some more work.
Great. I gave this a try, and after several tests, one thing was very clear: I don't yet understand how it works! :-) The test I used is a long table (generated with the attached program), served through a cgi that slows down the transfer rate (code attached for the cgi-program too). After installing the cgi-program, the test can be run like this: ./dillo-fltk "http://localhost/cgi-bin/slow.cgi?1000:/tmp/table3.html" (the number is the transfer rate in Bytes/second). You'll see one unnecessary erase/redraw per each new chunk of data that's out of the screen. With regard to my suggestion of not updating the table when the column sizes weren't changed, I thought of something akin to the attached patch (incomplete, working for AUTO tables, easy to finish, suitable for testing).
[...] Independent from that, I'm using my last patch regarding the redraws for quite a while now and it works pretty well here. Doesn't it make dillo2 much more useable for you, or do you see negative effects with it?
Yes surely more usable. The problem I saw long ago, was that on low CPU machines it requested more redraws, but this will be moot after the textblock/table optimizations. Most probably neither ASAP nor throttling will be needed then, and if the need ever arises I'd favor the idle-function throttling idea, as it looks simpler. Thanks for keeping up the good work! -- Cheers Jorge.-
participants (2)
-
jcid@dillo.org
-
Johannes.Hofmann@gmx.de