On Fri, 3 Oct 2003, David Martin wrote:
Jorge,
I would like to quickly comment on the todo list.
[Snip]
*Future Goals* (these may change in the future) Port dillo to GTK+2.0
[/Snip]
IMHO considering Dillo's concentration on speed and stability, it seems like it would be more appropriate to port the future Dillo to fltk not fat bloated GTK2.0.
I would expect that a staticly compiled Dillo-fltk binary would be considerably smaller then a dynamically compiled Dillo-GTK2 binary.
Food For Thought.
The FLTK idea is certainly an insteresting issue to analize. The porting task would be far from simple (if possible at all). Dillo does not only uses GTK+ for the user interface but for HTML rendering. Dillo has its own widget system (Dw), that's embedded inside GTK+ widgets, and that at its turn can also embedd GTK+ widgets again. This is the core of the porting problem. The main reason for porting dillo to GTK+2 (instead of sticking to 1.2.10) is Unicode support (explained in the [Project Notes] link). And yes, I've been somewhat scared by the size of GTK+2. For instance in Slackware it jumps from 4Mb to 17Mb! Now, considering that FLTK has Unicode support, gathering more information becomes an interesting thing to do. I don't know FLTK :(, but here is a list with some preliminary concerns (AFAIK): * Does it provide C bindings, or is for C++ only? * Does it have a table widget or similar to GTK+'s layout? * Can it be extended with Dw in the way stated above? * Unicode and antialiasing support status? Please don't get me wrong. This email is just a RFC to make a more informed decision on the issue. The current plan is to go with GTK+2, but if this path shows better, things can change. 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! Cheers Jorge.-
On Tue, 14 Oct 2003, Jorge Arellano Cid wrote:
* Does it provide C bindings, or is for C++ only? C++ only, although event callbacks are done using C style function pointers http://www.fltk.org/documentation.php/doc-2.0/intro.html#2_1
commented fltk example program http://www.fltk.org/documentation.php/doc-2.0/editor.html#editor
* Does it have a table widget or similar to GTK+'s layout? http://www.fltk.org/documentation.php/doc-2.0/Fl_Pack.html#Fl_Widget http://www.fltk.org/documentation.php/doc-2.0/Fl_Group.html#Fl_Group
* Unicode and antialiasing support status? antialiasing yes.
unicode support - seems, that it currently needs a patch for unicode support http://www.fltk.org/links.php?V111 google found this http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/53707
Hi, gtk-gnutella (http://gtk-gnutella.sf.net/) has similar performance problems with GTK2. There is a comment about a 1 Ghz PC.. Currently they do it like this way. #ifndef USE_GTK2 #define g_ascii_strcasecmp g_strcasecmp #define gdk_drawable_get_size gdk_window_get_size #endif Don't know if this is an option for dillo (recent talks) and what is left in the gtk2-patch after using such macros. Stephan
On Wed, 15 Oct 2003, Stephan Goetter wrote:
Hi,
gtk-gnutella (http://gtk-gnutella.sf.net/) has similar performance problems with GTK2. There is a comment about a 1 Ghz PC..
FWIW, the comment (15/Jun/2003) is: <q> * The GTK2 front-end is no longer experimental, albeit it is slower than the GTK1.2 front-end. This is due to the somewhat inefficient implementation of the underlying GTK library. Don't use GTK2 unless you have the equivalent of a 1 GHz Intel chip. </q> Cheers Jorge.-
On Wed, Oct 15, Stephan Goetter wrote:
gtk-gnutella (http://gtk-gnutella.sf.net/) has similar performance problems with GTK2. There is a comment about a 1 Ghz PC..
Currently they do it like this way.
#ifndef USE_GTK2 #define g_ascii_strcasecmp g_strcasecmp #define gdk_drawable_get_size gdk_window_get_size #endif
Don't know if this is an option for dillo (recent talks) and what is left in the gtk2-patch after using such macros.
No, there are much more dependencies, to GtkObject/GObject, to the GtkLayout widget, and to Pango, about which we actually hoped, that it may help us to solve many M17n problems. Sebastian
Hi! To have some facts for this discussion, there is a (basicly working) patch for the Gtk2 port, at <http://www.dillo.org/misc_files/gtk2.diff.gz>. It is a slightly modified version of a patch, which Jörgen sent me some time ago, and compiles with the current CVS (probably not with 0.7.3). Sebastian
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
On Thu, 2003-10-16 at 17:29, Stephen Lewis wrote:
dillo2 Time to load+render: ~3s Time to quit: 0.5s (estimated, "felt" slower than dillo1) Size: 14MB
If I recall correctly, there is a bug in the gtk2 patch which causes the text rendering routine to leak large amounts of memory. I have a fix for that somewhere. p.
In article <20031016032905.GA12137@ws0.localdomain>, Stephen Lewis <slewis@paradise.net.nz> writes
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:
can we assume/hope/plead (in the light of these numbers!) that any move to gtk2 is post-dillo-0.8 :-) Bob -- robert w hall
On Fri, 17 Oct 2003, robert w hall wrote:
In article <20031016032905.GA12137@ws0.localdomain>, Stephen Lewis <slewis@paradise.net.nz> writes
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:
can we assume/hope/plead (in the light of these numbers!) that any move to gtk2 is post-dillo-0.8 :-)
Read dillo goals ;) I believe that the move to gtk2 will be done only then, when it can be done without affecting dillo's usability as a light and fast browser.
On Fri, 17 Oct 2003, Madis Janson wrote:
On Fri, 17 Oct 2003, robert w hall wrote:
In article <20031016032905.GA12137@ws0.localdomain>, Stephen Lewis <slewis@paradise.net.nz> writes
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:
can we assume/hope/plead (in the light of these numbers!) that any move to gtk2 is post-dillo-0.8 :-)
Read dillo goals ;)
I believe that the move to gtk2 will be done only then, when it can be done without affecting dillo's usability as a light and fast browser.
Sure, dillo-0.8.0 will be a GTK1 app. BTW, I foresee almost a month to its release: we still have to sabilize dpi, and study/merge/modify some/all of Frank's patches. Last but not the least, please continue posting on the FLTK thread. It's the same! Cheers Jorge.-
participants (7)
-
Jorge Arellano Cid -
Madis Janson -
Philip Blundell -
robert w hall -
Sebastian Geerken -
Stephan Goetter -
Stephen Lewis