- Dillo-dev - lists.mailman3.com

towards a dillo-2.1 release

by jcid＠dillo.org

On Mon, Apr 20, 2009 at 10:46:49PM +0000, corvid wrote: > Jorge wrote: > > Of course any segfaults or regressions have high priority too. > > The dicache changes broke scaled multiscan images. > I don't think FltkImgbuf::newScan() gets called anymore. You're right. Can you look at it? BTW: FltkImgbuf::newScan() can be issued by adding a call to a_Image_new_scan(). -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Tue, Apr 21, 2009 at 09:01:46AM +0200, Hofmann Johannes wrote: > On Tue, Apr 21, 2009 at 07:48:11AM +0200, Hofmann Johannes wrote: > > On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > It'd be very good if we can complete these points for the 2.1 > > > release. Listed in no particular order: > > > > > > 1.- Dw documentation: online and as tarball. > > > We have good docs. but to generate them there's a need to > > > have: doxygen, graphviz, dot, latex and friends. That's why > > > having it online and as a tarball is a good idea. > > > 2.- Mapcity segfault > > > In www.mapcity.cl playing with the "Tipo Calle" while the > > > page is loading makes dillo segfault. If "Remote CSS" is > > > disabled, it doesn't happen (also OK in dillo-2.0). > > > 3.- New web site design > > > We have a new banner and after finding a good color palette > > > it may be ready to renew the site before 2.1 is announced. > > > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > > > 5.- Update "8 years" page (it's nine) > > > Yes, I should have done it already... > > > 6.- Configurable key bindings. > > > I'm reviewing this with Tim. Hopefully it will make it into > > > the 2.1 release. > > > 7.- Memory usage statistics > > > Scott has posted some data on this, in another thread. I'll > > > answer there. > > > > > > > > > I'd be working on 5, 6 and 3. > > > Volunteers please assign yourselves to the pending points. > > > > I will check 2. > > Ok, I can reproduce it now with > > trickle -d 15 dillo > > trickle (http://monkey.org/~marius/pages/?page=trickle) is really > cool for debugging! > > The problem is the repush caused by the arriving CSS stylesheet. It > deletes all form widgets and recreates them later. > I guess I can fix the segfault somehow, but there is a fundamental > problem if the user starts to fill in a form and then the repush > deletes all his data :( > > I currently see these options: > > 1. Disable forms while CSS stylesheets are pending. > 2. Disable the repush once the user started to fill in forms. > 3. Save form data in memory and restore it after repush. > This could also be used to restore form data when going back to a > forms page. > > Opinions? To implement what we had with dillo1: This is, inactive forms until the full form is loaded. Adding the restriction of pending stylesheets too (like in 1). This can solve the problem easily, and work even better when we add a maximum-simultaneous-connections to the server parameter in the future. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by Johannes.Hofmann＠gmx.de

On Tue, Apr 21, 2009 at 07:48:11AM +0200, Hofmann Johannes wrote: > On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > > Hi there, > > > > It'd be very good if we can complete these points for the 2.1 > > release. Listed in no particular order: > > > > 1.- Dw documentation: online and as tarball. > > We have good docs. but to generate them there's a need to > > have: doxygen, graphviz, dot, latex and friends. That's why > > having it online and as a tarball is a good idea. > > 2.- Mapcity segfault > > In www.mapcity.cl playing with the "Tipo Calle" while the > > page is loading makes dillo segfault. If "Remote CSS" is > > disabled, it doesn't happen (also OK in dillo-2.0). > > 3.- New web site design > > We have a new banner and after finding a good color palette > > it may be ready to renew the site before 2.1 is announced. > > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > > 5.- Update "8 years" page (it's nine) > > Yes, I should have done it already... > > 6.- Configurable key bindings. > > I'm reviewing this with Tim. Hopefully it will make it into > > the 2.1 release. > > 7.- Memory usage statistics > > Scott has posted some data on this, in another thread. I'll > > answer there. > > > > > > I'd be working on 5, 6 and 3. > > Volunteers please assign yourselves to the pending points. > > I will check 2. Ok, I can reproduce it now with trickle -d 15 dillo trickle (http://monkey.org/~marius/pages/?page=trickle) is really cool for debugging! The problem is the repush caused by the arriving CSS stylesheet. It deletes all form widgets and recreates them later. I guess I can fix the segfault somehow, but there is a fundamental problem if the user starts to fill in a form and then the repush deletes all his data :( I currently see these options: 1. Disable forms while CSS stylesheets are pending. 2. Disable the repush once the user started to fill in forms. 3. Save form data in memory and restore it after repush. This could also be used to restore form data when going back to a forms page. Opinions? Cheers, Johannes

April 21, 2009

towards a dillo-2.1 release

by Johannes.Hofmann＠gmx.de

On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > Hi there, > > It'd be very good if we can complete these points for the 2.1 > release. Listed in no particular order: > > 1.- Dw documentation: online and as tarball. > We have good docs. but to generate them there's a need to > have: doxygen, graphviz, dot, latex and friends. That's why > having it online and as a tarball is a good idea. > 2.- Mapcity segfault > In www.mapcity.cl playing with the "Tipo Calle" while the > page is loading makes dillo segfault. If "Remote CSS" is > disabled, it doesn't happen (also OK in dillo-2.0). > 3.- New web site design > We have a new banner and after finding a good color palette > it may be ready to renew the site before 2.1 is announced. > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > 5.- Update "8 years" page (it's nine) > Yes, I should have done it already... > 6.- Configurable key bindings. > I'm reviewing this with Tim. Hopefully it will make it into > the 2.1 release. > 7.- Memory usage statistics > Scott has posted some data on this, in another thread. I'll > answer there. > > > I'd be working on 5, 6 and 3. > Volunteers please assign yourselves to the pending points. I will check 2. Cheers, Johannes

April 21, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > Of course any segfaults or regressions have high priority too. The dicache changes broke scaled multiscan images. I don't think FltkImgbuf::newScan() gets called anymore.

April 21, 2009

memory use

by jcid＠dillo.org

Hi, On Fri, Mar 27, 2009 at 02:05:23PM -0600, Scott Scriven wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > BTW, it'd be good to have some memory usage data for dillo-2.1. > > A while ago, I noticed that dillo was using a lot of memory on a > specific page, and I didn't remember it doing that before. So I > tested a few versions and found that dillo2 uses more memory > initially, but less memory for large tables. Specifically: > > Memory use (in KiB) (on ubuntu 7.10 x86_64) > dillo-0.8.6/src/dillo: > 3692 file:///nothing > 4900 http://dillo.org/ > 45204 http://idlerpg.net/db.php > dillo-2.0/src/dillo: > 4700 file:///nothing > 6564 http://dillo.org/ > 36408 http://idlerpg.net/db.php > hg/dillo/src/dillo: > 4812 file:///nothing > 6684 http://dillo.org/ > 36756 http://idlerpg.net/db.php > > > Note: I remmeber having an awful memory footprint on 64bit > > Ubuntu. It didn't happen with 32bit. What's the current status, > > I don't know. > > I have both 64-bit and 32-bit ubuntu systems here, if you need > measurements. For example, I tried the above on my 32-bit box: > > Memory use (in KiB) (on ubuntu 8.04 i686) > dillo-0.8.6/src/dillo: > 4916 file:///nothing > 6504 http://dillo.org/ > 36824 http://idlerpg.net/db.php > dillo-2.0/src/dillo: > 3972 file:///nothing > 5732 http://dillo.org/ > 25144 http://idlerpg.net/db.php > hg/dillo/src/dillo: > 4036 file:///nothing > 5760 http://dillo.org/ > 25296 http://idlerpg.net/db.php Yes, 64bit uses more memory. I've collected the following numbers: (Ubuntu 8.10, 32bit) dillo-2.1: VSZ RSS COMMAND 8148 3872 ./dillo (empty) 26936 19196 ./dillo DragonFly.html (1.1MB HTML) 178684 174620 ./dillo MySQL-6.0.html (13MB HTML) 119788 113096 ./dillo MySQL-6.0.html (no IMG) f=7.2 dillo-0.8.6 VSZ RSS COMMAND 16592 3960 ./d086 83784 35748 ./d086 DragonFly.html (1.1MB HTML) 357320 293796 ./d086 MySQL-6.0.html (13MB HTML) 297224 234344 ./d086 MySQL-6.0.html (no IMG) f=16.3 firefox-3.0.8 VSZ RSS COMMAND 100884 37572 ./firefox 123184 59688 ./firefox DragonFly.html (1.1MB HTML) 312652 241016 ./firefox MySQL-6.0.html (13MB HTML) 328352 237560 ./firefox MySQL-6.0.html (no IMG) f=15 The 13MB page can be found at: http://dillo.org/test/mysql-6.0.doc.tar.bz2 The 1.1MB page can be found at: http://dillo.org/test/DragonFly.html.bz2 This numbers are the basis to claim that dillo2 uses half the memory footprint of dillo1. The "f" factor is the RSS for the MySQL manual (with no images), minus the empty RSS, minus 13MB, all divided by 13MB. The memory-cached page is substracted to get a clean HTML to Widgets factor. This is, if you have a 130KB html page, f*130KB will be used for rendering. It'd be good to have some wall-clock numbers too. Then the data can be tabulated and shown in the web site. Suggestions are highly welcomed. The VSZ and RSS numbers come from ps. I don't know of a better way to measure memory usage. The general idea is to have reproduceable numbers that show how dillo differs in memory and speed with other browsers. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

Hi there, It'd be very good if we can complete these points for the 2.1 release. Listed in no particular order: 1.- Dw documentation: online and as tarball. We have good docs. but to generate them there's a need to have: doxygen, graphviz, dot, latex and friends. That's why having it online and as a tarball is a good idea. 2.- Mapcity segfault In www.mapcity.cl playing with the "Tipo Calle" while the page is loading makes dillo segfault. If "Remote CSS" is disabled, it doesn't happen (also OK in dillo-2.0). 3.- New web site design We have a new banner and after finding a good color palette it may be ready to renew the site before 2.1 is announced. 4.- Debian/Ubuntu packages (after 2.1 final is ready) 5.- Update "8 years" page (it's nine) Yes, I should have done it already... 6.- Configurable key bindings. I'm reviewing this with Tim. Hopefully it will make it into the 2.1 release. 7.- Memory usage statistics Scott has posted some data on this, in another thread. I'll answer there. I'd be working on 5, 6 and 3. Volunteers please assign yourselves to the pending points. BTW, if you have important points to add to the list, please say so. Of course any segfaults or regressions have high priority too. TIA. -- Cheers Jorge.-

April 21, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by tim.nieradzik＠gmx.de

> What's the main point of dParser_parse_rc_line()? The main difference to the current implementation is that equal signs are interpreted as separator. Besides, it requires that ``line'', ``name'' and ``value'' are initialised with a specific length (in dpid/dpid.c it is set to 1024). The major advantage is that corrupt files (with very long lines) would not congest the RAM since we abort after 1024 characters. This is very unlikely though. > The comment says it extracts type, name and value, but it doesn't > extract type. Sorry, I had forgotten to update the description. In a previous version of my patch there has been a ``type'' attribute. As proposed, I removed it later on. Since then this function does basically the same job as dParser_get_rc_pair(). --Tim

April 20, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by jcid＠dillo.org

Hi Tim, On Fri, Apr 10, 2009 at 03:23:12PM +0000, Tim Nieradzik wrote: > This patch cleans up src/prefs.c and introduces the PrefsParser > (src/prefsparser.cc). With this patch I hesitate. What's the main point of dParser_parse_rc_line()? The comment says it extracts type, name and value, but it doesn't extract type. It introduces the need for separate buffers to copy the values, and more or less does the same. Please give some examples of the needed funcionality over the current implementation. -- Cheers Jorge.-

April 20, 2009

Instant client-side redirects (META refresh with delay=0)

by jcid＠dillo.org

Hi there, Please excuse me for being silent. Life has poured a few other important things to do over me (e.g. next week I have to move to another apartment). A patch for Instant client-side redirects is fresh in the repo. It took some time to develop because the whole idle/timeout mechanism needs a new API that allows to cancel queued functions. I didn't change the old API (the next release will keep it) but took some time to analyze and it may help with the redraw issue Johannes worked with, and also with hard-to-reproduce crashes. IIRC, Tim asked why several functions trigger from timeouts. Dillo is async. and the main driving function for I/O is Cache_process_queue(). This function is not reentrant, thus timeouts/idle calls allow for it to finish before a new action is taken. In general, there're several parts of dillo that need a more formal working definition or API. They've come to be with the implementation and it'd be good to define and document them, and hence not to have to go through all the involved code to find out how to implement something. I'll review the custom-keys patch series next, and try to re-start the work for the 2.1 release. Please test the patch. I've found it works well with the links in: http://git.kernel.org/gitweb.cgi -- Cheers Jorge.-

April 19, 2009