- Dillo-dev - lists.mailman3.com

Cookies performance

by corvid＠lavabit.com

Johannes wrote: > Can you please test attached patch, whether it compiles and makes a > difference for you? I speeds things up quite a bit here. We might > also want to cache SecretKey in a_Dpip_check_auth(). It sure seems faster to me!

Jan. 13, 2010

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 09:46:01PM +0100, Johannes Hofmann wrote: > On Tue, Jan 12, 2010 at 07:06:12PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > I noticed that since the recent DPI update pages which use > > > > > cookies load slower (e.g. fltk.org) > > > > > Do others also see that? It could also be OS specific. > > > > > > > > I thought it seemed weirdly slow _sometimes_. > > > > I'll have to throw some gprof at it and hope for something > > > > simple and embarrassing. > > > > > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > > > plugins.) > > > > > > I did some truss on the cookies dpi and found that it is reading > > > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. > > > > It looks like it checks it through a_Dpip_check_auth() when it > > gets or sets a msg. As for whether it needs to, I don't know. > > > > I tried a little gprof, but a modest amount of browsing and > > accepting cookies wasn't enough for the dpi to use up enough > > time for gprof to generate stats. > > Yah, I don't think it's CPU bound. There must be something else. I > will have a look at it. Can you please test attached patch, whether it compiles and makes a difference for you? I speeds things up quite a bit here. We might also want to cache SecretKey in a_Dpip_check_auth(). Cheers, Johannes

Jan. 12, 2010

title attrs (Re: [Dillo-dev] display: inline)

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 12, 2010 at 08:43:41PM +0000, corvid wrote: > > At the mention of setNonCssHints, I was hoping that whatever the > > prototype did would magically make it so that I could implement tooltips > > on arbitrary elements easily, but no such luck. > > Is the title attribute allowed on all elements and always results in > a tooltip? If so, we could rearrange things to parse common > attributes in a special function. title is part of %coreattrs along with id, class, and style. (and then there's also a title attr on the STYLE element) %coreattrs is part of %attrs, And what has %coreattrs or %attrs? Most things. As for behaviour, the spec says 'visual browsers frequently display the title as a "tool tip"'.

Jan. 12, 2010

display: inline

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 08:43:41PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > I started to experiment with the real solution, which means that the > > > display member of Style determines whether a (Text)block is created > > > or a ListItem, or whether just normal text is added. > > > The patch is still small, but as the change is pretty > > > fundamental, so I decided to put it in a separate repo for now. > > > You can find it at: > > > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > > > > I've updated this prototype a bit. It works quite well, the only > > drawback is the added complexity in html.cc. > > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > > an optional Html_tag_content_*() function for tags that create > > widgets or other content. This function is not called in the > > display:none case. > > The reason for the splitting into Html_tag_open_*() and > > Html_tag_content_*() is that styleEngine->setNonCssHints() is > > needed before we can get the current style. > > Only after that is done, we know the value of the display property > > and can decide whether to call Html_tag_content_*() or not. > > > > I'd like to get this into main line soon if you agree. > > Please let me know what you think. > > Maybe if Tags[] gets complicated enough, it will become possible to > talk Jorge into using NULL for the other default fields as well. > > At the mention of setNonCssHints, I was hoping that whatever the > prototype did would magically make it so that I could implement tooltips > on arbitrary elements easily, but no such luck. Is the title attribute allowed on all elements and always results in a tooltip? If so, we could rearrange things to parse common attributes in a special function.

Jan. 12, 2010

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 07:06:12PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > > Johannes wrote: > > > > I noticed that since the recent DPI update pages which use > > > > cookies load slower (e.g. fltk.org) > > > > Do others also see that? It could also be OS specific. > > > > > > I thought it seemed weirdly slow _sometimes_. > > > I'll have to throw some gprof at it and hope for something > > > simple and embarrassing. > > > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > > plugins.) > > > > I did some truss on the cookies dpi and found that it is reading > > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. > > It looks like it checks it through a_Dpip_check_auth() when it > gets or sets a msg. As for whether it needs to, I don't know. > > I tried a little gprof, but a modest amount of browsing and > accepting cookies wasn't enough for the dpi to use up enough > time for gprof to generate stats. Yah, I don't think it's CPU bound. There must be something else. I will have a look at it.

Jan. 12, 2010

display: inline

by corvid＠lavabit.com

Johannes wrote: > On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > > Hi, > > > > I started to experiment with the real solution, which means that the > > display member of Style determines whether a (Text)block is created > > or a ListItem, or whether just normal text is added. > > The patch is still small, but as the change is pretty > > fundamental, so I decided to put it in a separate repo for now. > > You can find it at: > > > > http://www.flpsed.org/hgweb/dillo_display/ > > > > I've updated this prototype a bit. It works quite well, the only > drawback is the added complexity in html.cc. > In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is > an optional Html_tag_content_*() function for tags that create > widgets or other content. This function is not called in the > display:none case. > The reason for the splitting into Html_tag_open_*() and > Html_tag_content_*() is that styleEngine->setNonCssHints() is > needed before we can get the current style. > Only after that is done, we know the value of the display property > and can decide whether to call Html_tag_content_*() or not. > > I'd like to get this into main line soon if you agree. > Please let me know what you think. Maybe if Tags[] gets complicated enough, it will become possible to talk Jorge into using NULL for the other default fields as well. At the mention of setNonCssHints, I was hoping that whatever the prototype did would magically make it so that I could implement tooltips on arbitrary elements easily, but no such luck.

Jan. 12, 2010

Cookies performance

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > > Johannes wrote: > > > I noticed that since the recent DPI update pages which use > > > cookies load slower (e.g. fltk.org) > > > Do others also see that? It could also be OS specific. > > > > I thought it seemed weirdly slow _sometimes_. > > I'll have to throw some gprof at it and hope for something > > simple and embarrassing. > > > > (I wonder whether it would be easy to do valgrind with dpid and the > > plugins.) > > I did some truss on the cookies dpi and found that it is reading > ~/.dillo/dpid_comm_keys quite often. Maybe that is related. It looks like it checks it through a_Dpip_check_auth() when it gets or sets a msg. As for whether it needs to, I don't know. I tried a little gprof, but a modest amount of browsing and accepting cookies wasn't enough for the dpi to use up enough time for gprof to generate stats.

Jan. 12, 2010

Cookies performance

by Johannes.Hofmann＠gmx.de

On Tue, Jan 12, 2010 at 05:42:03PM +0000, corvid wrote: > Johannes wrote: > > I noticed that since the recent DPI update pages which use > > cookies load slower (e.g. fltk.org) > > Do others also see that? It could also be OS specific. > > I thought it seemed weirdly slow _sometimes_. > I'll have to throw some gprof at it and hope for something > simple and embarrassing. > > (I wonder whether it would be easy to do valgrind with dpid and the > plugins.) I did some truss on the cookies dpi and found that it is reading ~/.dillo/dpid_comm_keys quite often. Maybe that is related.

Jan. 12, 2010

display: inline

by Johannes.Hofmann＠gmx.de

On Tue, Dec 08, 2009 at 06:56:55PM +0100, Johannes Hofmann wrote: > Hi, > > I started to experiment with the real solution, which means that the > display member of Style determines whether a (Text)block is created > or a ListItem, or whether just normal text is added. > The patch is still small, but as the change is pretty > fundamental, so I decided to put it in a separate repo for now. > You can find it at: > > http://www.flpsed.org/hgweb/dillo_display/ > I've updated this prototype a bit. It works quite well, the only drawback is the added complexity in html.cc. In addition to Html_tag_open_*() and Html_tag_clone_*(), there now is an optional Html_tag_content_*() function for tags that create widgets or other content. This function is not called in the display:none case. The reason for the splitting into Html_tag_open_*() and Html_tag_content_*() is that styleEngine->setNonCssHints() is needed before we can get the current style. Only after that is done, we know the value of the display property and can decide whether to call Html_tag_content_*() or not. I'd like to get this into main line soon if you agree. Please let me know what you think. Cheers, Johannes

Jan. 12, 2010

Cookies performance

by corvid＠lavabit.com

Johannes wrote: > I noticed that since the recent DPI update pages which use > cookies load slower (e.g. fltk.org) > Do others also see that? It could also be OS specific. I thought it seemed weirdly slow _sometimes_. I'll have to throw some gprof at it and hope for something simple and embarrassing. (I wonder whether it would be easy to do valgrind with dpid and the plugins.)

Jan. 12, 2010