- Dillo-dev - lists.mailman3.com

More Cache memory corruption

by onepoint＠starurchin.org

Hi everyone! No, I'm not dead. I am sorry I haven't been able to spend much time on Dillo recently. I've been lurking and it's good to see Dillo getting lots of developer love. Now the bad news: this HTML almost invariably crashes Dillo: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" /> </head> <body> </body> </html> The culprit is the <meta...> tag. Dillo always crashes in one of two ways: segmentation fault or glibc detecting memory corruption and aborting. In each case the backtrace from gdb is the same (verified by running Dillo 100 times (it only failed to crash twice)). The backtraces show that the Cache_* functions are freeing things they should not. Valgrind confirms this. I'm attaching backtraces and a valgrind log. I'm not sure how to debug this further. If anyone can suggest ways to trace this further I'll have a go. Looking forward to the dill2 release! This will be a great milestone. Jeremy Henty

Sept. 11, 2008

patch: more widget coloring

by jcid＠dillo.org

On Wed, Sep 10, 2008 at 11:07:02PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Sep 10, 2008 at 04:50:35PM -0400, Jorge Arellano Cid wrote: > > On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote: > > > On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote: > > > > > By the way, I was looking at that big page of inputs with > > > > > differently-colored backgrounds that I made in February... > > > > > At the time, I wrote that you guys had gotten the page down to > > > > > 0:06 to load with clear_double_buffer(), > > > > > immediate to load without it, and > > > > > 0:09 to destroy the page. > > > > > > > > > > The good news is that it now takes the same amount of time > > > > > with or without clear_double_buffer(), but > > > > > the bad news is that it takes 0:12 to load and 0:48 to close. > > > > > > > > If I assume that you can only have one instance of a widget in a view > > > > and add a break to the loop in FltkWidgetView::removeFltkWidget() > > > > once it finds it, the 0:48 becomes 0:03. > > > > > > Ah, interesting. In that case I'd ditch the canvasWidgets list > > > entirely as in attached patch. > > > > I don't know well that part of the code, but IIRC Sebastian > > used to render the same page into different widgets at the same > > time (e.g. also to thumbnail-sized one). > > > > AFAIU, this patch removes that functionality, which dillo doesn't > > use by now. Please correct me if I'm wrong. > > I don't think this patch removes any functionality. Not even an > unused one. > It simply relies on fltk to remember all the child widgets instead > of storing them again in a separate list. > > It's rather the recent FltkViewBase::drawRectangle() changes that > affect a scaled down display of the page contents. > The initial fix has now been reverted again (Commit messages > "reverted a patch in FltkViewBase::drawRectangle"). > > > > > BTW, why was the children drawing order reversed? > > > > That's because fltk does it that way. Group::find() searches > children backwards, so it's faster to e.g remove widgets in reverse > order (see comment in Group::find() in the fltk sources). > Also Group::children() get's only called once that way. > > I think it's safe to apply this patch - after some testing on other > platforms. Thanks for the explanation. Committed. -- Cheers Jorge.-

Sept. 11, 2008

patch: more widget coloring

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Sep 10, 2008 at 04:50:35PM -0400, Jorge Arellano Cid wrote: > On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote: > > On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote: > > > > By the way, I was looking at that big page of inputs with > > > > differently-colored backgrounds that I made in February... > > > > At the time, I wrote that you guys had gotten the page down to > > > > 0:06 to load with clear_double_buffer(), > > > > immediate to load without it, and > > > > 0:09 to destroy the page. > > > > > > > > The good news is that it now takes the same amount of time > > > > with or without clear_double_buffer(), but > > > > the bad news is that it takes 0:12 to load and 0:48 to close. > > > > > > If I assume that you can only have one instance of a widget in a view > > > and add a break to the loop in FltkWidgetView::removeFltkWidget() > > > once it finds it, the 0:48 becomes 0:03. > > > > Ah, interesting. In that case I'd ditch the canvasWidgets list > > entirely as in attached patch. > > I don't know well that part of the code, but IIRC Sebastian > used to render the same page into different widgets at the same > time (e.g. also to thumbnail-sized one). > > AFAIU, this patch removes that functionality, which dillo doesn't > use by now. Please correct me if I'm wrong. I don't think this patch removes any functionality. Not even an unused one. It simply relies on fltk to remember all the child widgets instead of storing them again in a separate list. It's rather the recent FltkViewBase::drawRectangle() changes that affect a scaled down display of the page contents. The initial fix has now been reverted again (Commit messages "reverted a patch in FltkViewBase::drawRectangle"). > > BTW, why was the children drawing order reversed? > That's because fltk does it that way. Group::find() searches children backwards, so it's faster to e.g remove widgets in reverse order (see comment in Group::find() in the fltk sources). Also Group::children() get's only called once that way. I think it's safe to apply this patch - after some testing on other platforms. Cheers, Johannes.

Sept. 10, 2008

patch: more widget coloring

by jcid＠dillo.org

On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote: > On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote: > > > By the way, I was looking at that big page of inputs with > > > differently-colored backgrounds that I made in February... > > > At the time, I wrote that you guys had gotten the page down to > > > 0:06 to load with clear_double_buffer(), > > > immediate to load without it, and > > > 0:09 to destroy the page. > > > > > > The good news is that it now takes the same amount of time > > > with or without clear_double_buffer(), but > > > the bad news is that it takes 0:12 to load and 0:48 to close. > > > > If I assume that you can only have one instance of a widget in a view > > and add a break to the loop in FltkWidgetView::removeFltkWidget() > > once it finds it, the 0:48 becomes 0:03. > > Ah, interesting. In that case I'd ditch the canvasWidgets list > entirely as in attached patch. I don't know well that part of the code, but IIRC Sebastian used to render the same page into different widgets at the same time (e.g. also to thumbnail-sized one). AFAIU, this patch removes that functionality, which dillo doesn't use by now. Please correct me if I'm wrong. BTW, why was the children drawing order reversed? -- Cheers Jorge.-

Sept. 10, 2008

[patch] remove asap parameter

by jcid＠dillo.org

On Wed, Sep 10, 2008 at 04:21:50PM +0200, Johannes Hofmann wrote: > On Tue, Sep 09, 2008 at 06:26:05PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 09, 2008 at 06:07:16PM +0200, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > any objections to remove the asap parameter as in attached patch? > > > It has been disabled for quite some time now. > > > > I read it, made some tests and it looks like the cleanup > > can even reduce the number of resize calls! > > Not sure wether I'm happy about that. It should not change > anything... > I will have a further look. You'll find: //static int calls = 0; //printf(" Layout::resizeIdle calls = %d\n", ++calls); both in layout.cc and fltkviewbase.cc. That's what I used to test. Note that networking may affect the counters. -- Cheers Jorge.-

Sept. 10, 2008

[patch] remove asap parameter

by jcid＠dillo.org

On Wed, Sep 10, 2008 at 04:20:50PM +0200, Johannes Hofmann wrote: > On Tue, Sep 09, 2008 at 07:32:14PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 09, 2008 at 06:07:16PM +0200, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > any objections to remove the asap parameter as in attached patch? > > > It has been disabled for quite some time now. > > > > I made a mistake during the dw2 commit, then fixed it, and it > > looks OK, but please check it. > > Looks good. Just a comment replacing a ifdef'd block is missing. > See attached patch. Committed. -- Cheers Jorge.-

Sept. 10, 2008

patch: more widget coloring

by corvid＠lavabit.com

Johannes wrote: > On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote: > > > By the way, I was looking at that big page of inputs with > > > differently-colored backgrounds that I made in February... > > > At the time, I wrote that you guys had gotten the page down to > > > 0:06 to load with clear_double_buffer(), > > > immediate to load without it, and > > > 0:09 to destroy the page. > > > > > > The good news is that it now takes the same amount of time > > > with or without clear_double_buffer(), but > > > the bad news is that it takes 0:12 to load and 0:48 to close. > > > > If I assume that you can only have one instance of a widget in a view > > and add a break to the loop in FltkWidgetView::removeFltkWidget() > > once it finds it, the 0:48 becomes 0:03. > > Ah, interesting. In that case I'd ditch the canvasWidgets list > entirely as in attached patch. > > Cheers, > Johannes > > PS: Can you share that test page? I just meant the one generated from the code on: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-February/003760.html

Sept. 10, 2008

patch: more widget coloring

by Johannes.Hofmann＠gmx.de

ok, here's the patch ... On Wed, Sep 10, 2008 at 05:05:34PM +0200, Johannes Hofmann wrote: > On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote: > > > By the way, I was looking at that big page of inputs with > > > differently-colored backgrounds that I made in February... > > > At the time, I wrote that you guys had gotten the page down to > > > 0:06 to load with clear_double_buffer(), > > > immediate to load without it, and > > > 0:09 to destroy the page. > > > > > > The good news is that it now takes the same amount of time > > > with or without clear_double_buffer(), but > > > the bad news is that it takes 0:12 to load and 0:48 to close. > > > > If I assume that you can only have one instance of a widget in a view > > and add a break to the loop in FltkWidgetView::removeFltkWidget() > > once it finds it, the 0:48 becomes 0:03. > > Ah, interesting. In that case I'd ditch the canvasWidgets list > entirely as in attached patch. > > Cheers, > Johannes > > PS: Can you share that test page? >

Sept. 10, 2008

patch: more widget coloring

by Johannes.Hofmann＠gmx.de

On Wed, Sep 10, 2008 at 04:56:47AM +0000, corvid wrote: > > By the way, I was looking at that big page of inputs with > > differently-colored backgrounds that I made in February... > > At the time, I wrote that you guys had gotten the page down to > > 0:06 to load with clear_double_buffer(), > > immediate to load without it, and > > 0:09 to destroy the page. > > > > The good news is that it now takes the same amount of time > > with or without clear_double_buffer(), but > > the bad news is that it takes 0:12 to load and 0:48 to close. > > If I assume that you can only have one instance of a widget in a view > and add a break to the loop in FltkWidgetView::removeFltkWidget() > once it finds it, the 0:48 becomes 0:03. Ah, interesting. In that case I'd ditch the canvasWidgets list entirely as in attached patch. Cheers, Johannes PS: Can you share that test page?

Sept. 10, 2008

[patch] remove asap parameter

by Johannes.Hofmann＠gmx.de

On Tue, Sep 09, 2008 at 06:26:05PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 09, 2008 at 06:07:16PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > any objections to remove the asap parameter as in attached patch? > > It has been disabled for quite some time now. > > I read it, made some tests and it looks like the cleanup > can even reduce the number of resize calls! Not sure wether I'm happy about that. It should not change anything... I will have a further look. Cheers, Johannes

Sept. 10, 2008

[patch] remove asap parameter

by Johannes.Hofmann＠gmx.de

On Tue, Sep 09, 2008 at 07:32:14PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 09, 2008 at 06:07:16PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > any objections to remove the asap parameter as in attached patch? > > It has been disabled for quite some time now. > > I made a mistake during the dw2 commit, then fixed it, and it > looks OK, but please check it. Looks good. Just a comment replacing a ifdef'd block is missing. See attached patch. Cheers, Johannes

Sept. 10, 2008

assertion failed during wildly clicking on links

by akemnade＠tzi.de

Hi, that was a false alarm. My mistake. fltk decided to put -Dbool=char for some reason into the compile flags in fltk-config. As some files do not use the fltk cflags, there are type conflicts. So I did without any further thinking I did a make CXX=".... -Dbool=char" And now... there is a cast in misc::asserrt() from a pointer to a char (because it is no macro). And if the least significant byte of the pointer is zero... After recompiling fltk the problem disappeared and I did not need any magic to compile dillo. Greetings Andreas Kemnade

Sept. 10, 2008

patch: more widget coloring

by corvid＠lavabit.com

> By the way, I was looking at that big page of inputs with > differently-colored backgrounds that I made in February... > At the time, I wrote that you guys had gotten the page down to > 0:06 to load with clear_double_buffer(), > immediate to load without it, and > 0:09 to destroy the page. > > The good news is that it now takes the same amount of time > with or without clear_double_buffer(), but > the bad news is that it takes 0:12 to load and 0:48 to close. If I assume that you can only have one instance of a widget in a view and add a break to the loop in FltkWidgetView::removeFltkWidget() once it finds it, the 0:48 becomes 0:03.

Sept. 10, 2008

patch: more widget coloring

by corvid＠lavabit.com

My main forms testing page has bg #00ffff from when I was first experimenting with widget colors. Some time ago, fltk changed so that selected checkboxes and radio buttons use selection_color(). I had this set to the inverse of the background. Red. Not a good combination to say the least. Well, I finally got around to trying to fix it up a little. By the way, I was looking at that big page of inputs with differently-colored backgrounds that I made in February... At the time, I wrote that you guys had gotten the page down to 0:06 to load with clear_double_buffer(), immediate to load without it, and 0:09 to destroy the page. The good news is that it now takes the same amount of time with or without clear_double_buffer(), but the bad news is that it takes 0:12 to load and 0:48 to close.

Sept. 10, 2008

[patch] remove asap parameter

by jcid＠dillo.org

On Tue, Sep 09, 2008 at 06:07:16PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > any objections to remove the asap parameter as in attached patch? > It has been disabled for quite some time now. I made a mistake during the dw2 commit, then fixed it, and it looks OK, but please check it. TIA. -- Cheers Jorge.-

Sept. 10, 2008

[patch] remove asap parameter

by jcid＠dillo.org

On Tue, Sep 09, 2008 at 06:07:16PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > any objections to remove the asap parameter as in attached patch? > It has been disabled for quite some time now. I read it, made some tests and it looks like the cleanup can even reduce the number of resize calls! Committed. -- Cheers Jorge.-

Sept. 10, 2008

[patch] remove asap parameter

by Johannes.Hofmann＠gmx.de

Hi Jorge, any objections to remove the asap parameter as in attached patch? It has been disabled for quite some time now. Cheers, Johannes

Sept. 9, 2008

Missing include directive for OpenBSD?

by jcid＠dillo.org

On Sun, Sep 07, 2008 at 01:51:19PM +0200, Christian Kellermann wrote: > Dear List, > > I have not updated dillo2 for a long time. Now that I have done so > I see that I have missed a lot! I needed the following tiny patch > to allow compilation on my OpenBSD 4.3 System: > > Index: dw/style.cc > =================================================================== > RCS file: /sfhome/cvs/dillo/dw2/dw/style.cc,v > retrieving revision 1.10 > diff -b -u -p -r1.10 style.cc > --- dw/style.cc 5 Sep 2008 12:58:52 -0000 1.10 > +++ dw/style.cc 7 Sep 2008 11:50:08 -0000 > @@ -24,6 +24,7 @@ > #include <string.h> > #include <unistd.h> > #include <ctype.h> > +#include <sys/stdint.h> > > #include "core.hh" > > > I am not sure whether this should have been caught by an autoconfig > check. Can someone point me into the right direction so this can > be changed to a proper patch? Yes, in dillo2's tree src/colors.h has a check that OpenBSD 4.3 is happy with. Please test it. > Thanks for your efforts and please keep up the good work! :-) Help is welcomed! -- Cheers Jorge.-

Sept. 8, 2008

load_images and multiple windows

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 08:28:28PM +0000, corvid wrote: > > Also, when switching to load_images=true, the "Load images" entry in > > the popup menu get's deactivated, even though the images of the > > current page are not yet loaded. > > I'd been ignoring it since I very rarely use that either, but all right, > here's a patch (will apply at an offset since my tree has forms code in > it that isn't worth putting into CVS until after release). Committed. -- Cheers Jorge.-

Sept. 8, 2008

default font_factor

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 09:33:47PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Sep 06, 2008 at 07:17:49PM +0000, corvid wrote: > > > Johannes wrote: > > > > recently the the default font_factor was changed from 1.0 to 1.2. > > > > Is there a reason for this change? > > > > > > I think 1.2 was the uncommented value in the old dillorc2. > > > > > > It would have made more sense for me to leave it as 1.0 and > > > change the elevens and twelves that it gets multiplied by... > > > > Yeah, having it 1.0 and scaling the base size makes sense to me. > > attached. > Committed. -- Cheers Jorge.-

Sept. 8, 2008

an example of page redraw problem when images load

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 10:26:03PM +0200, Johannes Hofmann wrote: > On Sat, Sep 06, 2008 at 04:28:55PM -0400, Jorge Arellano Cid wrote: > > On Sat, Sep 06, 2008 at 06:38:23PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Sep 06, 2008 at 03:53:34AM +0000, corvid wrote: > > > > > It was like dillo had treated the </div></div><p> as a <br> until that > > > > > click. I see that Textblock::addParbreak() has: > > > > > > > > > > /* Another break before? */ > > > > > if ((word = words->getRef(words->size () - 1)) && > > > > > word->content.type == core::Content::BREAK) { > > > > > word->content.breakSpace = > > > > > misc::max (word->content.breakSpace, space); > > > > > return; > > > > > } > > > > > > > > > > word = addWord (0, 0, 0, style); > > > > > word->content.type = core::Content::BREAK; > > > > > word->content.breakSpace = space; > > > > > wordWrap (words->size () - 1); > > > > > > > > > > For the sake of experiment, I stuck a > > > > > wordWrap (words->size () - 1); > > > > > before the return, and now it seems to work. > > > > > I imagine it must have to do with lastLine->breakSpace > > > > > getting updated... > > > > > > > > Yes, it seems so. Can you please test attached patch? It just updates > > > > lastLine->breakSpace instead of calling Textblock::wordWrap, > > > > because of the comment above Textblock::wordWrap... > > > > > > > > It also fixes some bugs in the redraw optimization. > > > > At least the <ol> issue (google.com) no longer happens here. > > > > > > It appears to be working well. > > > Thanks! > > > > Johannes: Should I commit this patch? > > Yes please. Committed. -- Cheers Jorge.-

Sept. 8, 2008

assertion failed during wildly clicking on links

by akemnade＠tzi.de

Hi, On Sat, 6 Sep 2008 22:03:16 +0200 Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hi, > > On Sat, Sep 06, 2008 at 09:34:29PM +0200, Andreas Kemnade wrote: > > Hi, > > > > I have seen the following, when clikling multiple times very fast on > > a link: > > Nav_open_url: new url='http://www.dwd.de/sid_520SLCXTTJJbtdSgR7JTsLGvkNt6TkS9ssWxDtLpSvVZtPCcyjPG!…' > > Connecting to 141.38.3.62 > > DilloHtml(): content type: text/html; charset=UTF-8 > > *** [unknown] Assertion failed! *** > > anchor 'headline_color_324A92' not defined > > Aborted > > That is typical. I suggest to disable asserts for the release and > some minutes later there is a new report of an assertion failure :-) > > > > > I tried www.dwd.de and then to click Wetter&Warnungen and the corresponding link. > > I can't reproduce it yet. Do you left-click on the link? If so, the > second click is already on the new page, right? > I did not wait for the new page to appear. It was on my freerunner. So I used the touch screen. I saw the assertion failure first when there was some bouncing. Then I tried to do it more systematically. > > > > I have not looked into the source yet, but I think there is a ressource management > > problem. > > Can you post a backtrace? > Well, there is a problem with too much use of -fomit-frame-pointer. So it is not that easy. Hmm, I'll try again with a breakpoint in misc::assert() this evening. Greetings Andreas Kemnade

Sept. 8, 2008

Fixed FltkViewBase::drawRectangle()

by corvid＠lavabit.com

Johannes wrote: > Hi Jorge, > > regarding the last change in fltkviewbase.cc: > > --- a/dw/fltkviewbase.ccSat Sep 06 19:51:25 2008 +0200 > +++ b/dw/fltkviewbase.ccSun Sep 07 10:51:04 2008 +0200 > @@ -384,7 +384,9 @@ > setcolor(((FltkColor*)color)->colors[shading]); > int x1 = translateCanvasXToViewX (x); > int y1 = translateCanvasYToViewY (y); > - ::fltk::Rectangle rect (x1, y1, width, height); > + int x2 = translateCanvasXToViewX (x + width); > + int y2 = translateCanvasYToViewY (y + height); > + ::fltk::Rectangle rect (x1, y1, x2 - x1, y2 - y1); > if (filled) > fillrect (rect); > else > > > To me it looks like this change is only necessary, if > translateCanvasXToViewX() would do some sort of scaling. Was there a > real problem, or did you change it just for consistency? Ah, that's what it was for -- fltkpreview has scaling, which I forgot about. (was fltkpreview intended to be hooked into something somewhere? I have mixed feelings about carrying around code that we don't have any particular plans to do anything with...)

Sept. 7, 2008

Missing include directive for OpenBSD?

by Johannes.Hofmann＠gmx.de

On Sun, Sep 07, 2008 at 02:16:38PM +0200, Christian Kellermann wrote: > * Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080907 14:09]: > > On Sun, Sep 07, 2008 at 01:51:19PM +0200, Christian Kellermann wrote: > > It's needed for the definition of intptr_t, right? > > Does #include <stdint.h> (without sys/) also help? > > Alternatively we could include <inttypes.h>. > > Aye, stdint.h also does it. Ok, thanks for the report. Johannes

Sept. 7, 2008

[patch] fix compilation on OpenBSD

by Johannes.Hofmann＠gmx.de

Hi, this fixes compilation on OpenBSD. Please verify on Linux. Cheers, Johannes

Sept. 7, 2008

Missing include directive for OpenBSD?

by Christian.Kellermann＠nefkom.net

* Johannes Hofmann <Johannes.Hofmann(a)gmx.de> [080907 14:09]: > On Sun, Sep 07, 2008 at 01:51:19PM +0200, Christian Kellermann wrote: > It's needed for the definition of intptr_t, right? > Does #include <stdint.h> (without sys/) also help? > Alternatively we could include <inttypes.h>. Aye, stdint.h also does it. Cheers, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Sept. 7, 2008

Missing include directive for OpenBSD?

by Johannes.Hofmann＠gmx.de

On Sun, Sep 07, 2008 at 01:51:19PM +0200, Christian Kellermann wrote: > Dear List, > > I have not updated dillo2 for a long time. Now that I have done so > I see that I have missed a lot! I needed the following tiny patch > to allow compilation on my OpenBSD 4.3 System: > > Index: dw/style.cc > =================================================================== > RCS file: /sfhome/cvs/dillo/dw2/dw/style.cc,v > retrieving revision 1.10 > diff -b -u -p -r1.10 style.cc > --- dw/style.cc 5 Sep 2008 12:58:52 -0000 1.10 > +++ dw/style.cc 7 Sep 2008 11:50:08 -0000 > @@ -24,6 +24,7 @@ > #include <string.h> > #include <unistd.h> > #include <ctype.h> > +#include <sys/stdint.h> > > #include "core.hh" > > > I am not sure whether this should have been caught by an autoconfig > check. Can someone point me into the right direction so this can > be changed to a proper patch? It's needed for the definition of intptr_t, right? Does #include <stdint.h> (without sys/) also help? Alternatively we could include <inttypes.h>. Cheers, Johannes

Sept. 7, 2008

Missing include directive for OpenBSD?

by Christian.Kellermann＠nefkom.net

Dear List, I have not updated dillo2 for a long time. Now that I have done so I see that I have missed a lot! I needed the following tiny patch to allow compilation on my OpenBSD 4.3 System: Index: dw/style.cc =================================================================== RCS file: /sfhome/cvs/dillo/dw2/dw/style.cc,v retrieving revision 1.10 diff -b -u -p -r1.10 style.cc --- dw/style.cc 5 Sep 2008 12:58:52 -0000 1.10 +++ dw/style.cc 7 Sep 2008 11:50:08 -0000 @@ -24,6 +24,7 @@ #include <string.h> #include <unistd.h> #include <ctype.h> +#include <sys/stdint.h> #include "core.hh" I am not sure whether this should have been caught by an autoconfig check. Can someone point me into the right direction so this can be changed to a proper patch? Thanks for your efforts and please keep up the good work! Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Sept. 7, 2008

load_images and multiple windows

by Johannes.Hofmann＠gmx.de

On Sat, Sep 06, 2008 at 08:28:28PM +0000, corvid wrote: > Johannes wrote: > > the load_images button toggles the global prefs.load_images > > variable but the buttons of other browser windows are not updated > > accordingly. > > Should load_images be a per window variable, or should we update the > > buttons in all other windows? > > Doesn't matter to me; I don't use it. > > > Also, when switching to load_images=true, the "Load images" entry in > > the popup menu get's deactivated, even though the images of the > > current page are not yet loaded. > > I'd been ignoring it since I very rarely use that either, but all right, > here's a patch (will apply at an offset since my tree has forms code in > it that isn't worth putting into CVS until after release). > Very nice. Now it also deactivates the "Load images" menu entry properly when all images have been loaded manually. Thanks, Johannes

Sept. 7, 2008

Fixed FltkViewBase::drawRectangle()

by Johannes.Hofmann＠gmx.de

Hi Jorge, regarding the last change in fltkviewbase.cc: --- a/dw/fltkviewbase.ccSat Sep 06 19:51:25 2008 +0200 +++ b/dw/fltkviewbase.ccSun Sep 07 10:51:04 2008 +0200 @@ -384,7 +384,9 @@ setcolor(((FltkColor*)color)->colors[shading]); int x1 = translateCanvasXToViewX (x); int y1 = translateCanvasYToViewY (y); - ::fltk::Rectangle rect (x1, y1, width, height); + int x2 = translateCanvasXToViewX (x + width); + int y2 = translateCanvasYToViewY (y + height); + ::fltk::Rectangle rect (x1, y1, x2 - x1, y2 - y1); if (filled) fillrect (rect); else To me it looks like this change is only necessary, if translateCanvasXToViewX() would do some sort of scaling. Was there a real problem, or did you change it just for consistency? Cheers, Johannes

Sept. 7, 2008

default font_factor

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 06, 2008 at 07:17:49PM +0000, corvid wrote: > > Johannes wrote: > > > recently the the default font_factor was changed from 1.0 to 1.2. > > > Is there a reason for this change? > > > > I think 1.2 was the uncommented value in the old dillorc2. > > > > It would have made more sense for me to leave it as 1.0 and > > change the elevens and twelves that it gets multiplied by... > > Yeah, having it 1.0 and scaling the base size makes sense to me. attached.

Sept. 6, 2008

load_images and multiple windows

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 09:00:33PM +0200, Johannes Hofmann wrote: > Hi, > > the load_images button toggles the global prefs.load_images > variable but the buttons of other browser windows are not updated > accordingly. > Should load_images be a per window variable, or should we update the > buttons in all other windows? A per window setting looks OK to me. That way people that use it only on certain pages (like me) are happy, and those that prefer text mode most of the time can have load_images=NO in dillo2rc. > Also, when switching to load_images=true, the "Load images" entry in > the popup menu get's deactivated, even though the images of the > current page are not yet loaded. This is a bug. -- Cheers Jorge.-

Sept. 6, 2008

an example of page redraw problem when images load

by Johannes.Hofmann＠gmx.de

On Sat, Sep 06, 2008 at 04:28:55PM -0400, Jorge Arellano Cid wrote: > On Sat, Sep 06, 2008 at 06:38:23PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Sep 06, 2008 at 03:53:34AM +0000, corvid wrote: > > > > It was like dillo had treated the </div></div><p> as a <br> until that > > > > click. I see that Textblock::addParbreak() has: > > > > > > > > /* Another break before? */ > > > > if ((word = words->getRef(words->size () - 1)) && > > > > word->content.type == core::Content::BREAK) { > > > > word->content.breakSpace = > > > > misc::max (word->content.breakSpace, space); > > > > return; > > > > } > > > > > > > > word = addWord (0, 0, 0, style); > > > > word->content.type = core::Content::BREAK; > > > > word->content.breakSpace = space; > > > > wordWrap (words->size () - 1); > > > > > > > > For the sake of experiment, I stuck a > > > > wordWrap (words->size () - 1); > > > > before the return, and now it seems to work. > > > > I imagine it must have to do with lastLine->breakSpace > > > > getting updated... > > > > > > Yes, it seems so. Can you please test attached patch? It just updates > > > lastLine->breakSpace instead of calling Textblock::wordWrap, > > > because of the comment above Textblock::wordWrap... > > > > > > It also fixes some bugs in the redraw optimization. > > > At least the <ol> issue (google.com) no longer happens here. > > > > It appears to be working well. > > Thanks! > > Johannes: Should I commit this patch? Yes please. Cheers, Johannes

Sept. 6, 2008

default font_factor

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 07:17:49PM +0000, corvid wrote: > Johannes wrote: > > recently the the default font_factor was changed from 1.0 to 1.2. > > Is there a reason for this change? > > I think 1.2 was the uncommented value in the old dillorc2. > > It would have made more sense for me to leave it as 1.0 and > change the elevens and twelves that it gets multiplied by... Yeah, having it 1.0 and scaling the base size makes sense to me. -- Cheers Jorge.-

Sept. 6, 2008

load_images and multiple windows

by corvid＠lavabit.com

Johannes wrote: > the load_images button toggles the global prefs.load_images > variable but the buttons of other browser windows are not updated > accordingly. > Should load_images be a per window variable, or should we update the > buttons in all other windows? Doesn't matter to me; I don't use it. > Also, when switching to load_images=true, the "Load images" entry in > the popup menu get's deactivated, even though the images of the > current page are not yet loaded. I'd been ignoring it since I very rarely use that either, but all right, here's a patch (will apply at an offset since my tree has forms code in it that isn't worth putting into CVS until after release).

Sept. 6, 2008

an example of page redraw problem when images load

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 06:38:23PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Sep 06, 2008 at 03:53:34AM +0000, corvid wrote: > > > It was like dillo had treated the </div></div><p> as a <br> until that > > > click. I see that Textblock::addParbreak() has: > > > > > > /* Another break before? */ > > > if ((word = words->getRef(words->size () - 1)) && > > > word->content.type == core::Content::BREAK) { > > > word->content.breakSpace = > > > misc::max (word->content.breakSpace, space); > > > return; > > > } > > > > > > word = addWord (0, 0, 0, style); > > > word->content.type = core::Content::BREAK; > > > word->content.breakSpace = space; > > > wordWrap (words->size () - 1); > > > > > > For the sake of experiment, I stuck a > > > wordWrap (words->size () - 1); > > > before the return, and now it seems to work. > > > I imagine it must have to do with lastLine->breakSpace > > > getting updated... > > > > Yes, it seems so. Can you please test attached patch? It just updates > > lastLine->breakSpace instead of calling Textblock::wordWrap, > > because of the comment above Textblock::wordWrap... > > > > It also fixes some bugs in the redraw optimization. > > At least the <ol> issue (google.com) no longer happens here. > > It appears to be working well. > Thanks! Johannes: Should I commit this patch? -- Cheers Jorge.-

Sept. 6, 2008

assertion failed during wildly clicking on links

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Sep 06, 2008 at 09:34:29PM +0200, Andreas Kemnade wrote: > Hi, > > I have seen the following, when clikling multiple times very fast on > a link: > Nav_open_url: new url='http://www.dwd.de/sid_520SLCXTTJJbtdSgR7JTsLGvkNt6TkS9ssWxDtLpSvVZtPCcyjPG!…' > Connecting to 141.38.3.62 > DilloHtml(): content type: text/html; charset=UTF-8 > *** [unknown] Assertion failed! *** > anchor 'headline_color_324A92' not defined > Aborted That is typical. I suggest to disable asserts for the release and some minutes later there is a new report of an assertion failure :-) > > I tried www.dwd.de and then to click Wetter&Warnungen and the corresponding link. I can't reproduce it yet. Do you left-click on the link? If so, the second click is already on the new page, right? > > I have not looked into the source yet, but I think there is a ressource management > problem. Can you post a backtrace? Cheers, Johannes

Sept. 6, 2008

assertion failed during wildly clicking on links

by akemnade＠tzi.de

Hi, I have seen the following, when clikling multiple times very fast on a link: Nav_open_url: new url='http://www.dwd.de/sid_520SLCXTTJJbtdSgR7JTsLGvkNt6TkS9ssWxDtLpSvVZtPCcyjPG!…' Connecting to 141.38.3.62 DilloHtml(): content type: text/html; charset=UTF-8 *** [unknown] Assertion failed! *** anchor 'headline_color_324A92' not defined Aborted I tried www.dwd.de and then to click Wetter&Warnungen and the corresponding link. I have not looked into the source yet, but I think there is a ressource management problem. Greetings Andreas Kemnade

Sept. 6, 2008

default font_factor

by corvid＠lavabit.com

Johannes wrote: > recently the the default font_factor was changed from 1.0 to 1.2. > Is there a reason for this change? I think 1.2 was the uncommented value in the old dillorc2. It would have made more sense for me to leave it as 1.0 and change the elevens and twelves that it gets multiplied by...

Sept. 6, 2008

load_images and multiple windows

by Johannes.Hofmann＠gmx.de

Hi, the load_images button toggles the global prefs.load_images variable but the buttons of other browser windows are not updated accordingly. Should load_images be a per window variable, or should we update the buttons in all other windows? Also, when switching to load_images=true, the "Load images" entry in the popup menu get's deactivated, even though the images of the current page are not yet loaded. Cheers, Johannes

Sept. 6, 2008

default font_factor

by Johannes.Hofmann＠gmx.de

Hi, recently the the default font_factor was changed from 1.0 to 1.2. Is there a reason for this change? Cheers, Johannes

Sept. 6, 2008

an example of page redraw problem when images load

by corvid＠lavabit.com

Johannes wrote: > On Sat, Sep 06, 2008 at 03:53:34AM +0000, corvid wrote: > > It was like dillo had treated the </div></div><p> as a <br> until that > > click. I see that Textblock::addParbreak() has: > > > > /* Another break before? */ > > if ((word = words->getRef(words->size () - 1)) && > > word->content.type == core::Content::BREAK) { > > word->content.breakSpace = > > misc::max (word->content.breakSpace, space); > > return; > > } > > > > word = addWord (0, 0, 0, style); > > word->content.type = core::Content::BREAK; > > word->content.breakSpace = space; > > wordWrap (words->size () - 1); > > > > For the sake of experiment, I stuck a > > wordWrap (words->size () - 1); > > before the return, and now it seems to work. > > I imagine it must have to do with lastLine->breakSpace > > getting updated... > > Yes, it seems so. Can you please test attached patch? It just updates > lastLine->breakSpace instead of calling Textblock::wordWrap, > because of the comment above Textblock::wordWrap... > > It also fixes some bugs in the redraw optimization. > At least the <ol> issue (google.com) no longer happens here. It appears to be working well. Thanks!

Sept. 6, 2008

an example of page redraw problem when images load

by Johannes.Hofmann＠gmx.de

On Sat, Sep 06, 2008 at 03:53:34AM +0000, corvid wrote: > The genode one didn't want to break for me either anymore, > so I went looking for an example from wikipedia. > If I go to http://en.wikipedia.org/wiki/Cysteine#Sheep > with images off, and click on the image of Cystine, > the text directly below the image jumps down. > > The source for that bit goes: > > <div class="thumb tright"> > <div class="thumbinner" style="width:152px;"><a href="/wiki/Image:Cystine-skeletal.png" class="image" title="Cystine, showing disulfide bond"><img alt="Cystine, > showing disulfide bond" src="file:///tmp/150px-Cystine-skeletal.png" width="150" height="191" border="0" class="thumbimage" /></a> > <div class="thumbcaption"> > <div class="magnify"><a href="/wiki/Image:Cystine-skeletal.png" class="internal" title="Enlarge"><img src="/skins-1.5/common/images/magnify-clip.png" width="15" height="11" alt="" /></a></div> > <a href="/wiki/Cystine" title="Cystine">Cystine</a>, showing <a href="/wiki/Disulfide_bond" title="Disulfide bond">disulfide bond</a></div> > </div> > </div> > <p>Cysteine is required... > > > It was like dillo had treated the </div></div><p> as a <br> until that > click. I see that Textblock::addParbreak() has: > > /* Another break before? */ > if ((word = words->getRef(words->size () - 1)) && > word->content.type == core::Content::BREAK) { > word->content.breakSpace = > misc::max (word->content.breakSpace, space); > return; > } > > word = addWord (0, 0, 0, style); > word->content.type = core::Content::BREAK; > word->content.breakSpace = space; > wordWrap (words->size () - 1); > > For the sake of experiment, I stuck a > wordWrap (words->size () - 1); > before the return, and now it seems to work. > I imagine it must have to do with lastLine->breakSpace > getting updated... Yes, it seems so. Can you please test attached patch? It just updates lastLine->breakSpace instead of calling Textblock::wordWrap, because of the comment above Textblock::wordWrap... It also fixes some bugs in the redraw optimization. At least the <ol> issue (google.com) no longer happens here. Cheers, Johannes

Sept. 6, 2008

8.68% of my time in assert()?

by jcid＠dillo.org

On Sat, Sep 06, 2008 at 12:21:56AM +0000, corvid wrote: > Jorge wrote: > > BTW, today I noticed this: > > > > After startup with blank page: > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.2 56136 4204 pts/8 S+ 19:59 0:00 ./dillo-fltk > > > > alarming VSZ when compared when what we had in July: > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.2 9676 4156 pts/13 S+ 14:57 0:00 ./dillo-fltk.03Jul > > > > > > -- > > Cheers > > Jorge.- > > > > PS: The good news at the bottom. I have basic Tabs working here! > > My VSZ at the moment is 8668. I blame tabs :) > Is there something interesting in /proc/$PID/maps? Nothing that I understand... Fortunately it's not Tabs, the sampled dillo is from 03 July, and today I noticed dillo1 also starts with a similar amount of VSZ. It looks like this system, Ubuntu 64bit, has something weird. I'll chack later, and polish Tabs a bit more. -- Cheers Jorge.-

Sept. 6, 2008

8.68% of my time in assert()?

by Johannes.Hofmann＠gmx.de

On Fri, Sep 05, 2008 at 08:03:23PM -0400, Jorge Arellano Cid wrote: > On Fri, Sep 05, 2008 at 08:55:17PM +0000, corvid wrote: > > Recompiled with -O2 -pg. > > Moved back and forth between two pages (10k and 130k) repeatedly. > > > > gprof said: > > > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 27.43 0.79 0.79 517177 0.00 0.00 dw::Textblock::wordWrap(int) > > 10.42 1.09 0.30 45 6.67 51.95 Html_write_raw(DilloHtml*, char*, int, int) > > 8.68 1.34 0.25 5845490 0.00 0.00 lout::misc::assert(bool, char const*, ...) > > 5.38 1.50 0.16 183777 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) > > 3.47 1.60 0.10 158682 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) > > 2.78 1.68 0.08 151303 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) > > 2.78 1.76 0.08 143 0.56 0.70 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) > > 2.78 1.84 0.08 21 3.81 4.91 dw::Textblock::~Textblock() > > 2.43 1.91 0.07 145864 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) > > 2.43 1.98 0.07 38885 0.00 0.00 Html_tag_index(char const*) > > 2.43 2.05 0.07 utf8towc > > 1.74 2.10 0.05 517177 0.00 0.00 dw::Textblock::getWordExtremes(dw::Textblock::Word*, dw::core::Extremes*) > > 1.74 2.15 0.05 158682 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core::Requisition*) > > 1.74 2.20 0.05 75140 0.00 0.00 dw::Textblock::addLine(int, bool) > > 1.74 2.25 0.05 utf8decode > > 1.74 2.30 0.05 DilloHtml::HtmlLinkReceiver::~HtmlLinkReceiver() > > 1.56 2.34 0.05 13231 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) > > 1.22 2.38 0.04 13351 0.00 0.00 dw::core::style::StyleAttrs::hashValue() > > 1.04 2.41 0.03 31375 0.00 0.00 Html_push_tag(DilloHtml*, int) > > 1.04 2.44 0.03 3861 0.01 0.02 a_Html_set_top_font(DilloHtml*, char const*, int, int, int) > > 1.04 2.47 0.03 193 0.16 0.23 dw::Textblock::rewrap() > > 0.69 2.49 0.02 73744 0.00 0.00 dStr_append_c > > 0.69 2.51 0.02 3020 0.01 0.02 a_Url_new > > ..(total 2.88 sec.) > > > > Naturally I thought that's a lot of time to spend in assert(). > > I wonder what would happen if I turned off BOUND_CHECKING in SimpleVector in lout/misc.hh. > > > > This gave > > > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 20.75 0.50 0.50 572066 0.00 0.00 dw::Textblock::wordWrap(int) > > 8.71 0.71 0.21 50 4.20 36.14 Html_write_raw(DilloHtml*, char*, int, int) > > 6.02 0.86 0.15 83051 0.00 0.00 dw::Textblock::addLine(int, bool) > > 5.81 1.00 0.14 202074 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) > > 5.60 1.13 0.14 174493 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) > > 5.39 1.26 0.13 157 0.83 0.83 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) > > 4.56 1.37 0.11 utf8towc > > 3.53 1.46 0.09 42701 0.00 0.00 Html_tag_index(char const*) > > 2.90 1.53 0.07 14483 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) > > 2.90 1.60 0.07 fltk::setfont(fltk::Font*, float) > > 2.49 1.66 0.06 174493 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core > > ::Requisition*) > > 2.49 1.72 0.06 34442 0.00 0.00 Html_tag_cleanup_at_close(DilloHtml*, int) > > 2.07 1.77 0.05 174517 0.00 0.00 dw::fltk::FltkPlatform::textWidth(dw::core::style::Font*, char const*, int > > ) > > 2.07 1.82 0.05 23 2.17 3.54 dw::Textblock::~Textblock() > > 2.07 1.87 0.05 fltk::getwidth(char const*, int) > > 1.66 1.91 0.04 166375 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) > > 1.66 1.95 0.04 9528 0.00 0.01 Url_object_new > > 1.24 1.98 0.03 14615 0.00 0.00 dw::core::style::StyleAttrs::hashValue() > > 1.24 2.01 0.03 7820 0.00 0.00 dw::core::style::StyleAttrs::equals(lout::object::Object*) > > 1.24 2.04 0.03 212 0.14 0.14 dw::Textblock::rewrap() > > 0.83 2.06 0.02 160393 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) > > 0.83 2.08 0.02 11374 0.00 0.00 dw::core::style::drawBackground(dw::core::View*, dw::core::Rectangle*, int > > , int, int, int, dw::core::style::Style*, bool) > > 0.83 2.10 0.02 9521 0.00 0.00 a_Url_free > > .. > > [snip] > > .. > > 0.00 2.41 0.00 44 0.00 0.00 lout::misc::assert(bool, char const*, ...) > > ..(total 2.41 sec.) > > > > > > I don't know whether -pg affects the ability to inline... > > and bounds checking is important... > > but it makes one think that maybe SimpleVector's get() and getRef() > > might be made cheaper, or we might at least avoid gratuitously making > > repeated get()s, since it turns out that they are not free. > > > > (_and_ I could have run many more trials, but the idea that assert() was > > even capable of reaching that high was alarming) > > Yes that's strange. We could disable asserts and bounds checking for the release. I'm haven't hit an assert or out of bounds error for quite some time. It's designed to be easily disabled. Cheers, Johannes

Sept. 6, 2008

8.68% of my time in assert()?

by Johannes.Hofmann＠gmx.de

On Sat, Sep 06, 2008 at 12:21:56AM +0000, corvid wrote: > Jorge wrote: > > BTW, today I noticed this: > > > > After startup with blank page: > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.2 56136 4204 pts/8 S+ 19:59 0:00 ./dillo-fltk > > > > alarming VSZ when compared when what we had in July: > > > > %MEM VSZ RSS TTY STAT START TIME COMMAND > > 0.2 9676 4156 pts/13 S+ 14:57 0:00 ./dillo-fltk.03Jul > > > > > > -- > > Cheers > > Jorge.- > > > > PS: The good news at the bottom. I have basic Tabs working here! > > My VSZ at the moment is 8668. I blame tabs :) > Is there something interesting in /proc/$PID/maps? I don't see any change in VSZ either. Cheers, Johannes

Sept. 6, 2008

an example of page redraw problem when images load

by corvid＠lavabit.com

The genode one didn't want to break for me either anymore, so I went looking for an example from wikipedia. If I go to http://en.wikipedia.org/wiki/Cysteine#Sheep with images off, and click on the image of Cystine, the text directly below the image jumps down. The source for that bit goes: <div class="thumb tright"> <div class="thumbinner" style="width:152px;"><a href="/wiki/Image:Cystine-skeletal.png" class="image" title="Cystine, showing disulfide bond"><img alt="Cystine, showing disulfide bond" src="file:///tmp/150px-Cystine-skeletal.png" width="150" height="191" border="0" class="thumbimage" /></a> <div class="thumbcaption"> <div class="magnify"><a href="/wiki/Image:Cystine-skeletal.png" class="internal" title="Enlarge"><img src="/skins-1.5/common/images/magnify-clip.png" width="15" height="11" alt="" /></a></div> <a href="/wiki/Cystine" title="Cystine">Cystine</a>, showing <a href="/wiki/Disulfide_bond" title="Disulfide bond">disulfide bond</a></div> </div> </div> <p>Cysteine is required... It was like dillo had treated the </div></div><p> as a <br> until that click. I see that Textblock::addParbreak() has: /* Another break before? */ if ((word = words->getRef(words->size () - 1)) && word->content.type == core::Content::BREAK) { word->content.breakSpace = misc::max (word->content.breakSpace, space); return; } word = addWord (0, 0, 0, style); word->content.type = core::Content::BREAK; word->content.breakSpace = space; wordWrap (words->size () - 1); For the sake of experiment, I stuck a wordWrap (words->size () - 1); before the return, and now it seems to work. I imagine it must have to do with lastLine->breakSpace getting updated...

Sept. 6, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

Jorge wrote: > BTW, today I noticed this: > > After startup with blank page: > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.2 56136 4204 pts/8 S+ 19:59 0:00 ./dillo-fltk > > alarming VSZ when compared when what we had in July: > > %MEM VSZ RSS TTY STAT START TIME COMMAND > 0.2 9676 4156 pts/13 S+ 14:57 0:00 ./dillo-fltk.03Jul > > > -- > Cheers > Jorge.- > > PS: The good news at the bottom. I have basic Tabs working here! My VSZ at the moment is 8668. I blame tabs :) Is there something interesting in /proc/$PID/maps?

Sept. 6, 2008

8.68% of my time in assert()?

by jcid＠dillo.org

On Fri, Sep 05, 2008 at 08:55:17PM +0000, corvid wrote: > Recompiled with -O2 -pg. > Moved back and forth between two pages (10k and 130k) repeatedly. > > gprof said: > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 27.43 0.79 0.79 517177 0.00 0.00 dw::Textblock::wordWrap(int) > 10.42 1.09 0.30 45 6.67 51.95 Html_write_raw(DilloHtml*, char*, int, int) > 8.68 1.34 0.25 5845490 0.00 0.00 lout::misc::assert(bool, char const*, ...) > 5.38 1.50 0.16 183777 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) > 3.47 1.60 0.10 158682 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) > 2.78 1.68 0.08 151303 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) > 2.78 1.76 0.08 143 0.56 0.70 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) > 2.78 1.84 0.08 21 3.81 4.91 dw::Textblock::~Textblock() > 2.43 1.91 0.07 145864 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) > 2.43 1.98 0.07 38885 0.00 0.00 Html_tag_index(char const*) > 2.43 2.05 0.07 utf8towc > 1.74 2.10 0.05 517177 0.00 0.00 dw::Textblock::getWordExtremes(dw::Textblock::Word*, dw::core::Extremes*) > 1.74 2.15 0.05 158682 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core::Requisition*) > 1.74 2.20 0.05 75140 0.00 0.00 dw::Textblock::addLine(int, bool) > 1.74 2.25 0.05 utf8decode > 1.74 2.30 0.05 DilloHtml::HtmlLinkReceiver::~HtmlLinkReceiver() > 1.56 2.34 0.05 13231 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) > 1.22 2.38 0.04 13351 0.00 0.00 dw::core::style::StyleAttrs::hashValue() > 1.04 2.41 0.03 31375 0.00 0.00 Html_push_tag(DilloHtml*, int) > 1.04 2.44 0.03 3861 0.01 0.02 a_Html_set_top_font(DilloHtml*, char const*, int, int, int) > 1.04 2.47 0.03 193 0.16 0.23 dw::Textblock::rewrap() > 0.69 2.49 0.02 73744 0.00 0.00 dStr_append_c > 0.69 2.51 0.02 3020 0.01 0.02 a_Url_new > ..(total 2.88 sec.) > > Naturally I thought that's a lot of time to spend in assert(). > I wonder what would happen if I turned off BOUND_CHECKING in SimpleVector in lout/misc.hh. > > This gave > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 20.75 0.50 0.50 572066 0.00 0.00 dw::Textblock::wordWrap(int) > 8.71 0.71 0.21 50 4.20 36.14 Html_write_raw(DilloHtml*, char*, int, int) > 6.02 0.86 0.15 83051 0.00 0.00 dw::Textblock::addLine(int, bool) > 5.81 1.00 0.14 202074 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) > 5.60 1.13 0.14 174493 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) > 5.39 1.26 0.13 157 0.83 0.83 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) > 4.56 1.37 0.11 utf8towc > 3.53 1.46 0.09 42701 0.00 0.00 Html_tag_index(char const*) > 2.90 1.53 0.07 14483 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) > 2.90 1.60 0.07 fltk::setfont(fltk::Font*, float) > 2.49 1.66 0.06 174493 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core > ::Requisition*) > 2.49 1.72 0.06 34442 0.00 0.00 Html_tag_cleanup_at_close(DilloHtml*, int) > 2.07 1.77 0.05 174517 0.00 0.00 dw::fltk::FltkPlatform::textWidth(dw::core::style::Font*, char const*, int > ) > 2.07 1.82 0.05 23 2.17 3.54 dw::Textblock::~Textblock() > 2.07 1.87 0.05 fltk::getwidth(char const*, int) > 1.66 1.91 0.04 166375 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) > 1.66 1.95 0.04 9528 0.00 0.01 Url_object_new > 1.24 1.98 0.03 14615 0.00 0.00 dw::core::style::StyleAttrs::hashValue() > 1.24 2.01 0.03 7820 0.00 0.00 dw::core::style::StyleAttrs::equals(lout::object::Object*) > 1.24 2.04 0.03 212 0.14 0.14 dw::Textblock::rewrap() > 0.83 2.06 0.02 160393 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) > 0.83 2.08 0.02 11374 0.00 0.00 dw::core::style::drawBackground(dw::core::View*, dw::core::Rectangle*, int > , int, int, int, dw::core::style::Style*, bool) > 0.83 2.10 0.02 9521 0.00 0.00 a_Url_free > .. > [snip] > .. > 0.00 2.41 0.00 44 0.00 0.00 lout::misc::assert(bool, char const*, ...) > ..(total 2.41 sec.) > > > I don't know whether -pg affects the ability to inline... > and bounds checking is important... > but it makes one think that maybe SimpleVector's get() and getRef() > might be made cheaper, or we might at least avoid gratuitously making > repeated get()s, since it turns out that they are not free. > > (_and_ I could have run many more trials, but the idea that assert() was > even capable of reaching that high was alarming) Yes that's strange. BTW, today I noticed this: After startup with blank page: %MEM VSZ RSS TTY STAT START TIME COMMAND 0.2 56136 4204 pts/8 S+ 19:59 0:00 ./dillo-fltk alarming VSZ when compared when what we had in July: %MEM VSZ RSS TTY STAT START TIME COMMAND 0.2 9676 4156 pts/13 S+ 14:57 0:00 ./dillo-fltk.03Jul -- Cheers Jorge.- PS: The good news at the bottom. I have basic Tabs working here!

Sept. 6, 2008

8.68% of my time in assert()?

by corvid＠lavabit.com

Recompiled with -O2 -pg. Moved back and forth between two pages (10k and 130k) repeatedly. gprof said: % cumulative self self total time seconds seconds calls ms/call ms/call name 27.43 0.79 0.79 517177 0.00 0.00 dw::Textblock::wordWrap(int) 10.42 1.09 0.30 45 6.67 51.95 Html_write_raw(DilloHtml*, char*, int, int) 8.68 1.34 0.25 5845490 0.00 0.00 lout::misc::assert(bool, char const*, ...) 5.38 1.50 0.16 183777 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) 3.47 1.60 0.10 158682 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) 2.78 1.68 0.08 151303 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) 2.78 1.76 0.08 143 0.56 0.70 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) 2.78 1.84 0.08 21 3.81 4.91 dw::Textblock::~Textblock() 2.43 1.91 0.07 145864 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) 2.43 1.98 0.07 38885 0.00 0.00 Html_tag_index(char const*) 2.43 2.05 0.07 utf8towc 1.74 2.10 0.05 517177 0.00 0.00 dw::Textblock::getWordExtremes(dw::Textblock::Word*, dw::core::Extremes*) 1.74 2.15 0.05 158682 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core::Requisition*) 1.74 2.20 0.05 75140 0.00 0.00 dw::Textblock::addLine(int, bool) 1.74 2.25 0.05 utf8decode 1.74 2.30 0.05 DilloHtml::HtmlLinkReceiver::~HtmlLinkReceiver() 1.56 2.34 0.05 13231 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) 1.22 2.38 0.04 13351 0.00 0.00 dw::core::style::StyleAttrs::hashValue() 1.04 2.41 0.03 31375 0.00 0.00 Html_push_tag(DilloHtml*, int) 1.04 2.44 0.03 3861 0.01 0.02 a_Html_set_top_font(DilloHtml*, char const*, int, int, int) 1.04 2.47 0.03 193 0.16 0.23 dw::Textblock::rewrap() 0.69 2.49 0.02 73744 0.00 0.00 dStr_append_c 0.69 2.51 0.02 3020 0.01 0.02 a_Url_new ..(total 2.88 sec.) Naturally I thought that's a lot of time to spend in assert(). I wonder what would happen if I turned off BOUND_CHECKING in SimpleVector in lout/misc.hh. This gave % cumulative self self total time seconds seconds calls ms/call ms/call name 20.75 0.50 0.50 572066 0.00 0.00 dw::Textblock::wordWrap(int) 8.71 0.71 0.21 50 4.20 36.14 Html_write_raw(DilloHtml*, char*, int, int) 6.02 0.86 0.15 83051 0.00 0.00 dw::Textblock::addLine(int, bool) 5.81 1.00 0.14 202074 0.00 0.00 dw::Textblock::addWord(int, int, int, dw::core::style::Style*) 5.60 1.13 0.14 174493 0.00 0.01 dw::Textblock::addText(char const*, dw::core::style::Style*) 5.39 1.26 0.13 157 0.83 0.83 dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) 4.56 1.37 0.11 utf8towc 3.53 1.46 0.09 42701 0.00 0.00 Html_tag_index(char const*) 2.90 1.53 0.07 14483 0.00 0.01 Html_get_attr2(DilloHtml*, char const*, int, char const*, int) 2.90 1.60 0.07 fltk::setfont(fltk::Font*, float) 2.49 1.66 0.06 174493 0.00 0.00 dw::Textblock::calcTextSize(char const*, dw::core::style::Style*, dw::core ::Requisition*) 2.49 1.72 0.06 34442 0.00 0.00 Html_tag_cleanup_at_close(DilloHtml*, int) 2.07 1.77 0.05 174517 0.00 0.00 dw::fltk::FltkPlatform::textWidth(dw::core::style::Font*, char const*, int ) 2.07 1.82 0.05 23 2.17 3.54 dw::Textblock::~Textblock() 2.07 1.87 0.05 fltk::getwidth(char const*, int) 1.66 1.91 0.04 166375 0.00 0.00 Html_process_space(DilloHtml*, char const*, int) 1.66 1.95 0.04 9528 0.00 0.01 Url_object_new 1.24 1.98 0.03 14615 0.00 0.00 dw::core::style::StyleAttrs::hashValue() 1.24 2.01 0.03 7820 0.00 0.00 dw::core::style::StyleAttrs::equals(lout::object::Object*) 1.24 2.04 0.03 212 0.14 0.14 dw::Textblock::rewrap() 0.83 2.06 0.02 160393 0.00 0.00 dw::Textblock::addSpace(dw::core::style::Style*) 0.83 2.08 0.02 11374 0.00 0.00 dw::core::style::drawBackground(dw::core::View*, dw::core::Rectangle*, int , int, int, int, dw::core::style::Style*, bool) 0.83 2.10 0.02 9521 0.00 0.00 a_Url_free .. [snip] .. 0.00 2.41 0.00 44 0.00 0.00 lout::misc::assert(bool, char const*, ...) ..(total 2.41 sec.) I don't know whether -pg affects the ability to inline... and bounds checking is important... but it makes one think that maybe SimpleVector's get() and getRef() might be made cheaper, or we might at least avoid gratuitously making repeated get()s, since it turns out that they are not free. (_and_ I could have run many more trials, but the idea that assert() was even capable of reaching that high was alarming)

Sept. 5, 2008