- Dillo-dev - lists.mailman3.com

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

a little experiment in showing form encoding as a tooltip

by corvid＠lavabit.com

Jorge wrote: > On Tue, Sep 02, 2008 at 10:30:40PM +0000, corvid wrote: > > Currently, there's a MSG that tells you what encoding a form was > > submitted as -- once it's submitting it. Obviously that's of > > limited usefulness when you want to know beforehand what will > > happen to any Japanese that you might type in, but on other hand, > > so many pages have forms that MSGs ahead of time would be annoying, > > besides the fact that a page may have multiple forms with different > > accept-charset attrs... > > > > Add to that the fact that one has to learn the hard way that > > you should only paste utf-8 into dillo2 and not, say, windows-1257. > > (and latin-1 works because fltk assumes it's latin-1 and does the > > conversion) > > > > So my quick little experiment: text/password/textarea form controls > > display a tooltip that reads > > > > enter: UTF-8 > > > > when UTF-8 will be submitted, and > > > > enter: UTF-8 > > send as: [some other encoding] > > > > otherwise. > > That's a good start... > > > > And it would clear things up for every person who tried to use > > google.com and wondered why non-latin-1 wasn't working when > > the oh-so-glorious dillo2 is supposed to be all UTF-8ed up. > > After all, it works in Firefox, right? > > (I've read that google pulls this idiocy with all of the little browsers. > > w3m, elinks, etc. Ignores the Accept-Charset header and does what it wants > > based on the User-Agent.) > > It may be a but more complicated. Non-technical users may be > left wondering what to do with that message or what UTF-8 is. For > instance, I don't know how to input latin1 from an X environment > that's set to utf8 (besides switching the whole thing to latin1). > > AFAIU, which is not much in this regard, if there's a way to > know what encoding the X server is using, dillo may iconv it into > utf8 and then to the "send-charset" if necessary (in a similar > way to what FLTK2 does with latin1). > > That way it works for the user without further steps. Of course > I may be wrong in this appreciation! > > > Would you mind explaining it further? > > It deserves at least an entry in the FAQ (which I would read > with interest, certainly ;). I had been looking at this from the perspective of: "even though copy and paste of latin2 between two rxvt's works, I can't paste latin2 into dillo", but I suppose I'm not quite sure that X wouldn't have enough magic in it for latin2 to work for someone properly set up in a latin2 locale. Looking at the format of the Compose file, I _think_ it still wouldn't work for them (<Multi_key> <L> <minus> becomes "\243", not "Lstroke". Of course they don't need the Compose mapping, but the fact that it's going toward the octal encoding rather than a character seems significant). Putting aside what character encoding to enter, not knowing what encoding a form will be submitted as bugs me. Somewhat related to all of this: local files that are text/plain.

Sept. 5, 2008

Keyboard scrolling and focus patch

by jcid＠dillo.org

On Thu, Sep 04, 2008 at 10:51:56PM +0200, Johannes Hofmann wrote: > > > > Please test, and enjoy. > > Nice. Thanks you! :-) > > PS: I've also made some experiments with tabs, but it seems FLTK2 > > has problems to handle window widgets inside the tabs... > > Why do You need a window (instead of a simple widget) inside the > tabs? Currently dillo2 uses window, so Ctrl-N can open a new window. It would have been convenient not to change the current code base, and to reuse that already tested part for both tabs and new windows (with the idea of being able to open tabs or new windows with the same code). It may be possible by switching class UI to derive from Group, and to add an enclosing window only when necessary, and thus arrange for widgets inside Tabs and Window for windows. The problem I foresee with the latter scheme is messing with the event passing between widgets and windows... I'll have to experiment with it, and get some working code. Now, if *somebody* wants to help then, that'd be great! ;-) -- Cheers Jorge.-

Sept. 4, 2008

a little experiment in showing form encoding as a tooltip

by jcid＠dillo.org

Hi, On Tue, Sep 02, 2008 at 10:30:40PM +0000, corvid wrote: > Currently, there's a MSG that tells you what encoding a form was > submitted as -- once it's submitting it. Obviously that's of > limited usefulness when you want to know beforehand what will > happen to any Japanese that you might type in, but on other hand, > so many pages have forms that MSGs ahead of time would be annoying, > besides the fact that a page may have multiple forms with different > accept-charset attrs... > > Add to that the fact that one has to learn the hard way that > you should only paste utf-8 into dillo2 and not, say, windows-1257. > (and latin-1 works because fltk assumes it's latin-1 and does the > conversion) > > So my quick little experiment: text/password/textarea form controls > display a tooltip that reads > > enter: UTF-8 > > when UTF-8 will be submitted, and > > enter: UTF-8 > send as: [some other encoding] > > otherwise. That's a good start... > And it would clear things up for every person who tried to use > google.com and wondered why non-latin-1 wasn't working when > the oh-so-glorious dillo2 is supposed to be all UTF-8ed up. > After all, it works in Firefox, right? > (I've read that google pulls this idiocy with all of the little browsers. > w3m, elinks, etc. Ignores the Accept-Charset header and does what it wants > based on the User-Agent.) It may be a but more complicated. Non-technical users may be left wondering what to do with that message or what UTF-8 is. For instance, I don't know how to input latin1 from an X environment that's set to utf8 (besides switching the whole thing to latin1). AFAIU, which is not much in this regard, if there's a way to know what encoding the X server is using, dillo may iconv it into utf8 and then to the "send-charset" if necessary (in a similar way to what FLTK2 does with latin1). That way it works for the user without further steps. Of course I may be wrong in this appreciation! Would you mind explaining it further? It deserves at least an entry in the FAQ (which I would read with interest, certainly ;). -- Cheers Jorge.-

Sept. 4, 2008

Keyboard scrolling and focus patch

by jcid＠dillo.org

Hi there, Finally a patch for fixing keyboard scrolling, and focus change with the keyboard, was committed. I had hopes to be able to commit before the release, and so I'm happy. :) Now switching focus from the viewport to the location bar, using the keyboard, works consistently (Try TAB/Shift-TAB) and also the scrolling keys (Up, Down, Left, Right, PgUp/b, PgDn/space, etc) are kept in a responsive state. It's been a long time, and I almost forgot the nice feeling of scrolling with the keyboard (e.g. try the space bar to skip past the links menu most pages have these days). Please test, and enjoy. -- Cheers Jorge.- PS: I've also made some experiments with tabs, but it seems FLTK2 has problems to handle window widgets inside the tabs...

Sept. 4, 2008

a little experiment in showing form encoding as a tooltip

by corvid＠lavabit.com

Currently, there's a MSG that tells you what encoding a form was submitted as -- once it's submitting it. Obviously that's of limited usefulness when you want to know beforehand what will happen to any Japanese that you might type in, but on other hand, so many pages have forms that MSGs ahead of time would be annoying, besides the fact that a page may have multiple forms with different accept-charset attrs... Add to that the fact that one has to learn the hard way that you should only paste utf-8 into dillo2 and not, say, windows-1257. (and latin-1 works because fltk assumes it's latin-1 and does the conversion) So my quick little experiment: text/password/textarea form controls display a tooltip that reads enter: UTF-8 when UTF-8 will be submitted, and enter: UTF-8 send as: [some other encoding] otherwise. And it would clear things up for every person who tried to use google.com and wondered why non-latin-1 wasn't working when the oh-so-glorious dillo2 is supposed to be all UTF-8ed up. After all, it works in Firefox, right? (I've read that google pulls this idiocy with all of the little browsers. w3m, elinks, etc. Ignores the Accept-Charset header and does what it wants based on the User-Agent.) A different option might be to have a form popup menu to show info such as submission encoding, hidden inputs, and so on. As for the code, unfortunately I have setTooltip()s all over the place because Style's Tooltip field is for real tooltips, not for char*s to stuff into pre-existing tooltips such as the fltk widgets have.

Sept. 3, 2008