Hi, to test how dillo behaves on huge pages, I downloaded the mysql manual as a single html page: http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz With this page I noticed that the drawRegion in FltkViewBase can grow pretty large which slows down loading the page. Attached patch limits the size of the drawRegion to 16 rectangles. With this patch (and HUGE_FILESIZE in cache.c increased to 16M) dillo works pretty well on this huge page. Better than dillo1 and firefox! One problem is that clicking on anchor links (to anchors within the page) reloads the page which take some time. Also memory usage gets pretty high (250M with images disabled). I'm experimenting with reducing the size of struct Word in textblock.hh by moving the highlight stuff out of struct Word and into Textblock. This brings memory usage down to 199M. However, I don't know the highlighting stuff enough to be sure I don't break anything. This probabely falls into the "premature optimization" category anyway. Cheers, Johannes
On Mon, May 19, 2008 at 06:23:11PM +0200, Johannes Hofmann wrote:
Hi,
to test how dillo behaves on huge pages, I downloaded the mysql manual as a single html page: http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz
With this page I noticed that the drawRegion in FltkViewBase can grow pretty large which slows down loading the page. Attached patch limits the size of the drawRegion to 16 rectangles.
With this patch (and HUGE_FILESIZE in cache.c increased to 16M) dillo works pretty well on this huge page. Better than dillo1 and firefox!
Great! Committed. BTW, this is one of the important points whe should list in the dillo2 features page. Please somebody remember this!
One problem is that clicking on anchor links (to anchors within the page) reloads the page which take some time.
Some time ago, we had anchors hooked with direct scroll jumps. It was instantaneous, but the navigation stack wasn't modified and thus BACK didn't go to the original place. It can be hooked to jump again, but in that case, the navigation stack needs to be modified accordingly. This creates two paths for the same logic operation inside dillo (which increases the mantainability costs). That said, if there's a simple way to do it, I agree.
Also memory usage gets pretty high (250M with images disabled). I'm experimenting with reducing the size of struct Word in textblock.hh by moving the highlight stuff out of struct Word and into Textblock. This brings memory usage down to 199M. However, I don't know the highlighting stuff enough to be sure I don't break anything. This probabely falls into the "premature optimization" category anyway.
Not at all. I'd say the important part is to know whether that optimization can be done without breaking the underlying model for everything else (a question Sebastian is the most knowledgeable person to answer in the case of dw2). -- Cheers Jorge.-
On Mon, May 19, 2008 at 01:18:01PM -0400, Jorge Arellano Cid wrote:
On Mon, May 19, 2008 at 06:23:11PM +0200, Johannes Hofmann wrote:
Hi,
to test how dillo behaves on huge pages, I downloaded the mysql manual as a single html page: http://downloads.mysql.com/docs/refman-5.1-en.html.tar.gz
With this page I noticed that the drawRegion in FltkViewBase can grow pretty large which slows down loading the page. Attached patch limits the size of the drawRegion to 16 rectangles.
With this patch (and HUGE_FILESIZE in cache.c increased to 16M) dillo works pretty well on this huge page. Better than dillo1 and firefox!
Great!
Committed.
BTW, this is one of the important points whe should list in the dillo2 features page. Please somebody remember this!
One problem is that clicking on anchor links (to anchors within the page) reloads the page which take some time.
Some time ago, we had anchors hooked with direct scroll jumps. It was instantaneous, but the navigation stack wasn't modified and thus BACK didn't go to the original place.
It can be hooked to jump again, but in that case, the navigation stack needs to be modified accordingly. This creates two paths for the same logic operation inside dillo (which increases the mantainability costs). That said, if there's a simple way to do it, I agree.
I will have a look at this.
Also memory usage gets pretty high (250M with images disabled). I'm experimenting with reducing the size of struct Word in textblock.hh by moving the highlight stuff out of struct Word and into Textblock. This brings memory usage down to 199M. However, I don't know the highlighting stuff enough to be sure I don't break anything. This probabely falls into the "premature optimization" category anyway.
Not at all.
I'd say the important part is to know whether that optimization can be done without breaking the underlying model for everything else (a question Sebastian is the most knowledgeable person to answer in the case of dw2).
Ok, I will cleanup what I have and send a patch to the list for review. It would be really great, if Sebastian could have a look at it. Cheers, Johannes
participants (2)
-
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de