- Dillo-dev - lists.mailman3.com

Cookies performance

by Johannes.Hofmann＠gmx.de

On Thu, Jan 14, 2010 at 11:25:31AM +0900, furaisanjin wrote: > Hi all. > > This may be FreeBSD (8.0R) specific or my local proxy specific but if > src/IO/dpi.c contains TCP_NODELAY, I got lots of this error messages > when the page contains lots of pictures. > > Http_connect_socket ERROR: Connection reset by peer What page is that, or does it happen on all pages with many images? Is it using https? > > so that several pictures aren't drawn. I agree that page rendering is > much faster if TCP_NODELAY is set but that isn't good on my > environment. We need find the issue for sure, but generally TCP_NODELAY should not cause any connection resets, so I think there is a bug somewhere that get's triggered by the different timing now. Cheers, Johannes

Jan. 14, 2010

Cookies performance

by furaisanjin＠gmail.com

Hi all. This may be FreeBSD (8.0R) specific or my local proxy specific but if src/IO/dpi.c contains TCP_NODELAY, I got lots of this error messages when the page contains lots of pictures. Http_connect_socket ERROR: Connection reset by peer so that several pictures aren't drawn. I agree that page rendering is much faster if TCP_NODELAY is set but that isn't good on my environment. Regards, furaisanjin

Jan. 14, 2010

release process (Re: [Dillo-dev] Re: even more cookies SECURITY)

by Johannes.Hofmann＠gmx.de

On Wed, Jan 13, 2010 at 07:54:52AM +0000, corvid wrote: > Jorge wrote: > > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > > Do we currently have anything that needs to be > > > fixed/implemented before a release would be sensible? > > > > Not that I remember. The only problem I recall was the error > > message you reported with cookies and later seemed to be working > > somehow. > > > > Besides, AFAIS the repo is stable enough to start rolling the > > release process. > > The matter of the display code prompts the question of where we want > to draw a feature freeze line. Yes, that's the question. I think the display stuff will need about three weeks until we can release it. If we want to release earlier I would leave it out. Cheers, Johannes

Jan. 13, 2010

release process (Re: [Dillo-dev] Re: even more cookies SECURITY)

by corvid＠lavabit.com

Jorge wrote: > On Mon, Jan 04, 2010 at 11:38:03PM +0000, corvid wrote: > > Do we currently have anything that needs to be > > fixed/implemented before a release would be sensible? > > Not that I remember. The only problem I recall was the error > message you reported with cookies and later seemed to be working > somehow. > > Besides, AFAIS the repo is stable enough to start rolling the > release process. The matter of the display code prompts the question of where we want to draw a feature freeze line.

Jan. 13, 2010

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