March 2008 - Dillo-dev - lists.mailman3.com

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 02:14:06PM +0000, place wrote: > > On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > > > I made a dStr_dstrcat(). > > > > > > > What's the main advantage of it, over dStr_append_l() ? > > > > I see the convenience and clarity of passing two parameters instead > > of three, but on the other hand, keeping APIs reduced to a functional > > minimum, helps to remember and to choose the right function call. > > > > There may be a point I don't yet see... > > Nope, that's all there was to it. > And I don't have a strong opinion about it, so that's fine. Does anybody else have some experience/theory/article/knowledge on API design that can enlighten us? ;) -- Cheers Jorge.-

March 18, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

Hi, On Sat, Mar 15, 2008 at 07:58:34PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Mar 14, 2008 at 06:53:08PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > below is another patch to reduce the redraws caused by resizing > > > tables. A new method Layout::queueDrawExcept(), that requests the > > > drawing of a rectangle except another rectangle is added. > > > It is then used in widget.cc to redraw the area that was previously > > > occupied by a widget, but is no longer occupied after a resize or move. > > > This makes it possible to redraw less when a table resizes. > > > All in all it should reduce the flicker a bit when loading table > > > based pages. > > > > On the topic of reducing the flicker, I'm far of an expert and > > please correct me if I'm wrong. AFAIU, the current design draws > > the background color before the widget content. > > > > This is: if you have an html page as big table, in dillo, it > > will become a table inside a textblock. When the textblock is > > asked to redraw, it will _erase_ the table with its background > > color and ask its child (the table) to redraw. Causing flicker. > > Yes, that's true. > In addition, before anything is drawn, the rectangle to be drawn is > already cleared with the background color in FltkViewBase::draw() > (the fillrect () calls). Oh, I haven't noticed those calls. > > > > If this is true, a big gain could come from a different > > approach: just draw the surroundings of the widgets and ask the > > child widgets to redraw. > > > > This way widgets aren't erased beforehand, and can also decide > > not to redraw themselves when nothing has changed. > > > > I have worked a bit on this idea, and the attached patch mocks > > the idea hackishly. It draws the "padding" area of the CSS box > > (see the picture in namespacedw_1_1core_1_1style.html in dw docs) > > > > Please give it a review and share your comments, > > corrections and thoughts. > > I've been thinking about something similar as well, but I don't > think it will work out generally. > The main problem is text drawing and maybe transparent widgets > (don't know whether they exist already). Probably drawing text over a background image qualifies as "transparent text widget". > Anyway, for drawing text, you need to erase the area first. > Just comment out the fillrect () calls in FltkViewBase::draw() to > see what I mean :-) Yes, I did. Quite clear example. > Therefore, we will always have flicker, when drawing text. > > The good news is that all the flicker can be avoided easily with > some double buffering technique. And from dillo1 we even know that > this is not necessarily slow :-) > > So for me the flicker itself is not that much of a problem. > It may be an indicator for unnecessary redraws, which should be > avoided to save CPU power. But I think current cvs is already > pretty good in this regard. That makes me happy, because since the queueDrawExcept() patch, flickering has reduced even more. I'm yet to test on a slow system though. > > So I would propose to start to think about efficient double > buffering similar to what I had posted in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-November/003379.html > but platform independent using fltk2 support. Sure, and we still have the reosurce of tunning the refresh rate as in formerly proposed patches. I agree with your proposal. And if someday (soon I hope) we start working together with the FLTK guys, they will have lots of advice on how to tune things up. -- Cheers Jorge.-

March 18, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > Hi, > > below is another patch to reduce the redraws caused by resizing > tables. A new method Layout::queueDrawExcept(), that requests the > drawing of a rectangle except another rectangle is added. > It is then used in widget.cc to redraw the area that was previously > occupied by a widget, but is no longer occupied after a resize or move. > This makes it possible to redraw less when a table resizes. > All in all it should reduce the flicker a bit when loading table > based pages. Committed! -- Cheers Jorge.-

March 18, 2008

saving files under recent fltk snapshots?

by Johannes.Hofmann＠gmx.de

On Mon, Mar 17, 2008 at 06:56:26PM +0000, place wrote: > I moved to snapshot 6066 (I'd been on 5990) the other day, and now I > notice that dillo is unresponsive after I save a file. > > Seen in the 6059 announcement (http://fltk.org/articles.php?L791) > "+ Changed the modal event loop of file_chooser() and dir_chooser() > to use a new exec() method that delegates to Window::exec() internally. > This exec() method should handle unpleasant side effects with other modal > windows when closing the file_chooser dialog window. > > + Updated FileChooser.fl to reflect modifications made in the cxx/h files. > Please do not edit these files directly (except the include header) > Thanks." > > If anybody's tried a recent snapshot: Does it work for you? There seems to be a bug report regarding this already: http://fltk.org/newsgroups.php?s5234+gfltk.bugs+v5241+T0 Cheers, Johannes

March 18, 2008

Re: patch: concatenate Dstrs

by place＠gobigwest.com

> On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > > I made a dStr_dstrcat(). > > > > What's the main advantage of it, over dStr_append_l() ? > > I see the convenience and clarity of passing two parameters instead > of three, but on the other hand, keeping APIs reduced to a functional > minimum, helps to remember and to choose the right function call. > > There may be a point I don't yet see... Nope, that's all there was to it. And I don't have a strong opinion about it, so that's fine.

March 18, 2008

saving files under recent fltk snapshots?

by jcid＠dillo.org

Hi, On Mon, Mar 17, 2008 at 06:56:26PM +0000, place wrote: > I moved to snapshot 6066 (I'd been on 5990) the other day, and now I > notice that dillo is unresponsive after I save a file. > > Seen in the 6059 announcement (http://fltk.org/articles.php?L791) > "+ Changed the modal event loop of file_chooser() and dir_chooser() > to use a new exec() method that delegates to Window::exec() internally. > This exec() method should handle unpleasant side effects with other modal > windows when closing the file_chooser dialog window. > > + Updated FileChooser.fl to reflect modifications made in the cxx/h files. > Please do not edit these files directly (except the include header) > Thanks." > > If anybody's tried a recent snapshot: Does it work for you? The same happened to me! Now I'm using fltk-2.0.x-r5990 plus this patch: ------------------------------------------------------------------------------ diff -pru fltk-2.0.x-r5990/src/message.cxx fltk-2.0.x-r6059/src/message.cxx --- fltk-2.0.x-r5990/src/message.cxx 2007-11-28 16:42:30.000000000 -0300 +++ fltk-2.0.x-r6059/src/message.cxx 2008-02-22 20:00:05.000000000 -0300 @@ -1,5 +1,5 @@ // -// "$Id: message.cxx 5990 2007-11-28 19:42:30Z dejan $" +// "$Id: message.cxx 6041 2008-02-22 23:00:05Z fabien $" // // Copyright 1998-2006 by Bill Spitzak and others. // @@ -429,7 +429,7 @@ static const char* input_innards(const c const char* defstr, uchar type) { int r = innards("?", defstr ? defstr : "", type, fmt, ap, fltk::cancel, fltk::ok, 0); - return r>=0 ? textfield->text() : 0; + return r>0 ? textfield->text() : 0; } /*! ------------------------------------------------------------------------------ -- Cheers Jorge.-

March 18, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

Hi, On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > I made a dStr_dstrcat(). > What's the main advantage of it, over dStr_append_l() ? I see the convenience and clarity of passing two parameters instead of three, but on the other hand, keeping APIs reduced to a functional minimum, helps to remember and to choose the right function call. There may be a point I don't yet see... -- Cheers Jorge.-

March 18, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by jcid＠dillo.org

On Mon, Mar 17, 2008 at 09:09:04PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080317 19:40]: > > On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > below is a small optinization to Html_parse_entities (). > > > > Committed. > > Unfortunately this misses the newly introduced inbuf_t for iconv compatibility. > See my patch below: > > Kind Regards, Ooops, committed. -- Cheers Jorge.-

March 18, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080317 19:40]: > On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > > Hi, > > > > below is a small optinization to Html_parse_entities (). > > Committed. Unfortunately this misses the newly introduced inbuf_t for iconv compatibility. See my patch below: Kind Regards, Christian Index: src/html.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v retrieving revision 1.53 diff -b -u -r1.53 html.cc --- src/html.cc 17 Mar 2008 19:04:11 -0000 1.53 +++ src/html.cc 17 Mar 2008 20:19:21 -0000 @@ -3844,7 +3844,8 @@ int rc = 0; Dstr *output; const int bufsize = 128; - char *buffer, *inPtr, *outPtr; + inbuf_t *inPtr; + char *buffer, *outPtr; size_t inLeft, outRoom; bool bad_chars = false; -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 17, 2008

patch: multipart/form-data CRLF

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:29:32PM +0000, place wrote: > Happened to notice in the RFC that multipart types must use CRLF between > body parts. Committed. > PS It was a bit annoying to figure out that http.c needed to be changed, > which suggests that it would have been better for me to store the boundary > string in DilloUrl somewhere after all. It happens. A long time ago I dedicated a long time to generate a minimal perfect hash function for finding HTML tags. It turned out that asimple binary search was simpler and with the same performance... -- Cheers Jorge.-

March 17, 2008