GTK2 performance and Dillo

["Robin Rowe" <rower MovieEditor com>]

Hi. Dillo is a very small fast web browser (400kb executable). Stephan Lewis
posted some interesting performances tests yesterday comparing GTK1 and GTK2
running Dillo.

Can anyone illuminate further on the size and performance differences
between GTK1 and GTK2?

Thanks!

Robin
---------------------------------------------------------------------------
Robin Rowe MovieEditor com   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software

----- Original Message ----- 
From: "Stephen Lewis" <slewis paradise net nz>
To: "Dillo mailing list" <dillo-dev auriga wearlab de>
Sent: Wednesday, October 15, 2003 8:29 PM
Subject: [Dillo-dev] Re: gtk2 and dillo ( was FLTK )


> On Tue, Oct 14, 2003 at 10:20:11AM -0300, Jorge Arellano Cid wrote:
> >   This  is  also  an  RFC  for information on GTK+2 (speed, size,
> > linkings etc).
> >
> >   Please  back  your  opinions  with  links,  docs, facts or with
> > whatever  helps  better  to  understand the point. Maybe a single
> > email can show there's no way to do it, or maybe not!
>
> I've just been playing with the GTK+2 patch, and I've got some
> numbers (I won't call them fact :), and opinions:
>
> These are on a 500Mhz Intel PC, with 256MB RAM.  dillo2 refers to
> the patched GTK+2 version, dillo1 is GTK1.2 based ( both todays CVS ).
> The machine is running FreeBSD 5.1
> The numbers are basically estimated, but I tried each test several
> times and got similar results.
>
> Test 1: Base load times
> dillo1
>     Time to load+render: ~1s
>     Time to quit: instantaneous
>     Size (from top): 7MB
> dillo2
>     Time to load+render: ~3s
>     Time to quit: 0.5s (estimated, "felt" slower than dillo1)
>     Size: 14MB
>
> Test2: Loading a 1.8MB html file, styled text, bulletted lists, tables
>        of text
> dillo1
>     Time to load: 3s
>         extra time to finish rendering: 6s
>     Time to quit: ~2s
>     Size: 56MB
> dillo2
>     Time to load: 1m20s real according to the time command, more like
>                   2m30s due to swapping
>         extra time to finish rendering: 10s
>     Time to close: 1m20s
>     Size: 220MB
>
>
> Test3: Loading a trivial 70k html file ( no images or tables, just text
>        in a list )
> dillo1
>     Time to load+render: 1s
>     Time to quit: instantaneous
>     Size: 9MB
>
> dillo2
>     Time to load: 5s
>     Time to render: <1s
>     Time to quit: < 1s
>     Size: 16MB
>
>
> Test4: Loading a 1.5MB html file (fairly simple, no images, few tables)
> dillo1
>     Time to load: ~3s
>         extra time to finish rendering: ~6s
>     Time to quit: ~1s
>     Size: 36MB
>     Time to scroll entire length of document by holding pagedown: ~26s
>
> dillo2
>     Time to load: 40s
>         extra time to finish rendering: 2s
>     Time to quit: 16s
>     Size: 125MB
>     Time to scroll entire length of document by holding pagedown: 20s
>
> A couple of behavioural notes:
> 1) Progressive rendering wasn't useful in dillo2, you get an initial
>    draw (which is largely useless), then dillo2 blocks, then the final
>    draw.
> 2) Scrolling is implemented in quite a different fashion in GTK2 vs
>    GTK1, which has a higher latency, slower "feel".  I suspect that
>    GTK+1 would feel as bad using its algorithm if it were using
>    anti-aliased fonts ( opinion based on little evidence )
>    This isn't really a problem for sequential scrolling, but random
>    seeking by dragging the scrollbar is very irritating under GTK+2
>    I think this is due to changes relating to the "draw" signal,
>    mentioned in the GTK1.2-2.0 changelog:
>    ... GTK+ merges all invalid regions, and sends expose events to the
>    widget in an idle handler for the invalid regions. ...
>
> The things that I found pretty much unusable were
>   - load times ( for anything non-trivial )
>   - close times ( for large documents )
>   - memory usage
>
> If it's not possible to mitigate these in a GTK+2 version of dillo,
> then I personally wouldn't find it to be a usable choice anymore (which
> would suck - I like dillo).
>
> On the other hand, if those numbers could be brought down to even, say,
> twice what dillo1 requires, I think it would be fine (at least, on my
> hardware).
>
> --
> Stephen Lewis
>
> _______________________________________________
> Dillo-dev mailing list
> Dillo-dev lists auriga wearlab de
> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev