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