- Dillo-dev - lists.mailman3.com

[patch] redraw optimization now including tables

by Johannes.Hofmann＠gmx.de

Hello, below is an improved version of the redraw optimization. It now also covers table based pages - at least to some point. The challenge is to make the already commited optimization work recursively. Other than I originally thought topLevel is always a Textblock. Table based pages simply consist of a Textblock with a huge Table as child widget. Textblock now needs to avoid redrawing the child area when the table size increases. The redrawing is left to the Table-code, which then can be optimized. Please test carefully and report any anomalies you find. Regards, Johannes

Feb. 27, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by jcid＠dillo.org

On Mon, Feb 04, 2008 at 08:10:25PM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > > > Also, what would you think of me either > > > > > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) > > > > OK. > > attached. > > I renamed it a_Cookies_get_query() in an effort > to suggest that it now returned more than just > the cookies. > > > Everything looks fine when I watch the headers, > but I don't use dillo for anything that _relies_ > on cookies working properly. Committed. > So...anyone who habitually uses cookies might want > to give this a bit of a test. Now that's on CVS it should get a share of testing... -- Cheers Jorge.- PS: sorry for the long wait.

Feb. 24, 2008

PATCH: small improvement to the "can't start dpid daemon" error message

by jcid＠dillo.org

On Sat, Feb 23, 2008 at 09:27:30PM +0000, Jeremy Henty wrote: > > A common cause of the "can't start dpid daemon" error is clicking on a > link with a typo'ed HREF that has an invalid URL scheme (eg. 'ttp://' > instead of 'http://', to cite the real-life example that prompted this > patch). But the error message gives *no* context that would help to > diagnose the problem. If it cited the URL scheme it would save a lot > of time. (I had to start Firefox before I realised what the problem > was!) Here's a patch to do that. Thanks Jeremy. Committed! -- Cheers Jorge.-

Feb. 24, 2008

[patch] fix redraw problem with findText

by jcid＠dillo.org

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.-

Feb. 24, 2008

PATCH: small improvement to the "can't start dpid daemon" error message

by onepoint＠starurchin.org

A common cause of the "can't start dpid daemon" error is clicking on a link with a typo'ed HREF that has an invalid URL scheme (eg. 'ttp://' instead of 'http://', to cite the real-life example that prompted this patch). But the error message gives *no* context that would help to diagnose the problem. If it cited the URL scheme it would save a lot of time. (I had to start Firefox before I realised what the problem was!) Here's a patch to do that. Jeremy Henty

Feb. 23, 2008

[patch] fix redraw problem with findText

by Johannes.Hofmann＠gmx.de

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);

Feb. 23, 2008

[patch] optimize redraw after resize for textblocks

by jcid＠dillo.org

Hi, On Mon, Feb 18, 2008 at 05:50:43PM +0100, Johannes Hofmann wrote: > Hello, > > here comes my attempt to avoid unnecessary redraws > caused by images that are not visible. > The first patch makes some minor optimizations to the drawing code > and disables the use of the asap parameter for better testing. > The second patch replaces the general queueDrawTotal() in > Layout::resizeIdle () with more specific redraw calls in > widgets that can be topLevel. > Currently only Textblock is optimized. > The idea is that resizing child widgets in a textblock don't affect > the layout of the textblock above the resizing widget. So only the > area below needs to be redrawn. Excellent! Committed. (Of course this is a work that is in state of flux, but I preferred to have this basis in CVS). BTW, this explanation: "The idea is that resizing child widgets in a textblock don't affect the layout of the textblock above the resizing widget." should make its way, as a comment, into the code. > I think that does not hold for tables, but perhaps other > optimizations are possible here? Ideas anyone? Yes, after my work on tables, I think if the column sizes don't change, the rule could be the same used for the textblock. Please excuse me for my lack of time the past week and these days, I'll answer and work as time permits... -- Cheers Jorge.-

Feb. 21, 2008

[patch] optimize redraw after resize for textblocks

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Feb 21, 2008 at 04:57:29AM +0000, place wrote: > Hi Johannes, > > I finally got around to applying this today... > Are you seeing any problems with text highlighting? > > If I repeat searches so that the page scrolls some -- but not far enough > for the previous instance to scroll off screen -- the previous instance > stays highlighted and the current instance isn't highlighted. > > It's entirely possible that I screwed something up, but when I > diffed my trees, I didn't notice anything wrong... No, I'm seeing this too now. I will try to fix it. Thanks for testing, Johannes

Feb. 21, 2008

[patch] optimize redraw after resize for textblocks

by Johannes.Hofmann＠gmx.de

Hello, here comes my attempt to avoid unnecessary redraws caused by images that are not visible. The first patch makes some minor optimizations to the drawing code and disables the use of the asap parameter for better testing. The second patch replaces the general queueDrawTotal() in Layout::resizeIdle () with more specific redraw calls in widgets that can be topLevel. Currently only Textblock is optimized. The idea is that resizing child widgets in a textblock don't affect the layout of the textblock above the resizing widget. So only the area below needs to be redrawn. I think that does not hold for tables, but perhaps other optimizations are possible here? Ideas anyone? The effect is visible e.g. on http://chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10.… but not on table based pages. Cheers, Johannes

Feb. 18, 2008

Dillo screenshot on my ipaq

by akemnade＠tzi.de

Hi, On Sat, 9 Feb 2008 12:57:33 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Please excuse my lack of knowledge on the iPAQ. Whad does it > involve to get dillo2 running on it? > You need somehow a build environment for it. mainly it is about compiling binutils and gcc with --target=arm-linux and installing the familiar packages (including dev-packages) for the required libraries into the search path of the compiler. And a pkg-config with the correct paths compiled in is also helpful (name it arm-linux-pkg-config) And then it is time to compile fltk, dw and dillo with ./configure --host=arm-linux and pay attention that it uses correct paths for every library. And then it is the usual make && make DESTDIR=/somewhere/ install for dillo2. In /somewhere/ you can build a tarball of the installed files and unpack it on the ipaq. I have not looked into package creation yet, but the packet format looks the same as for debian just with another suffix (an ar archive which contains a data.tar.gz (with the real data, a control.tar.gz which some control information like dependencies and install scripts) and another file used as a marker, older versions of familiar seem to bind the three files together as a gzip'ed tarfile). But I'll try to find something out about it. Greetings Andreas Kemnade

Feb. 18, 2008