I ran my tests again, only with antialiasing disabled this time (for font sizes between 6 and 14). The results of the first run are repeated here, and dillo2n represents the new runs. Please refer to my previous email for a detailed description of the tests. I also experimented with sub-pixel rendering, without antialiasing (dillo2ns) and with antialiasing (dillo2s) First run: ---------- Results: time1 time2 delta/30 prps mem(KB) dillo1 1.36s 1.82s 15ms 67 2516 dillo2 3.10s 6.90s 126ms 8 3624 dillo2s 3.23s 7.16s 131ms 7.6 n/a dillo2n 3.34s 5.33s 66ms 15 3628 dillo2ns 3.16s 4.94s 59ms 17 n/a Conclusion: While disabling antialiasing rendering doesn't seem to change anything for the start time (which was already acceptable, IMHO), it doubles the speed when scrooling entire pages! With this setting, dillo2n became useable. Not quite as snappy as dillo1 (still 4 times slower on redraws), but very acceptable. Turning off antialiasing doesn't change the amount memory used. Turning on sub-pixel rendering doesn't affect the rendering time, but seems to improve the quality only when used with antialiasing. However, my fonts look ugly with gtk-2.0 and I don't seem to be able to find any setting that helps (it seems to scale non-scalable fonts). With gtk-1.2, the font look good. Second run: skipped. Third run: ---------- This is a scaled down version of the second run. I took the same file and kept only the first 2000 line. The test file is 684 KB. Results: time1 time2 mem(KB) dillo1 5.1s 35s 12708 dillo2 31.5s 2m53s 33520 dillo2n 29.9s n/a 33652 Conclusion: Nothing changed here: loading big pages is still painful brings the whole machine down on its knees when swapping starts. For the record, the real time (time2) was 2m10s, but the load on my system was completely different today, so I don't this it compares to yesterdays results. Fourth run: skipped. Fifth run: ---------- This is a free run of internet browsing, to get an overall feeling. No numbers for this one. Includes browsing several sites, open up to 8 windows, switch between them and close them all, click on the floppy disk to save URL. Selecting text was fast. Conclusion: Still feels heavy. Faster on scrolling, acceptable, in fact, but any operation is still taking enough time for me to notice I'm actually waiting for the redraws to occur. Particularly when overlapping redraws occur (X Expose events), like switching from one window to another. Also, as another poster noticed, *closing* windows takes a significant amount of time (this is certainly related to freeing much more memory than dillo1). I timed another operation to give you an idea: I opened and closed (cancel) the save URL dialog 5 times in dillo2n, substracted the start and closing time as usual and divided by 5: 1.4s each time (user time, real time more like 6s). Same experience with dillo1: 0.09s. Now that's what I'm talking about! (could not get any real time, most of it is spent by moving the mouse from one button to another) Final conclusion: ----------------- If we go with gtk-2.0, we absolutely need to document this antialiasing setting: I had a hard time finding that some information was on fontconfig.org! If we also can point to font de-uglyfication of gtk-2.0, that would help a lot. Regardless, like Stephen said, memory usage is a huge problem. I assume this cause by the libraries and the implementation in dillo is the same (i.e: dillo's structure did not grow x2.5 because the the port). Until this problem is solved, I don't think gtk-2.0 is a viable option for dillo. Disabling antialiasing definitely solves most of my concerns about speed: if only I could get the font to be as clean as gtk-1.2, I would be happy. Best, EG PS: the patch is still alpha-quality and has a lot of rendering bugs: font-factor screws-up positionning, text selection hightlights at the wrong place, etc.

Hello, I have used FLTK a little, and from what I know of it it has less features than GTK, FLTK is probably faster, but GTK was made for GIMP, a drawing program, so I guess it has the functionality you need for a browser. If the current Dillo would be too slow then I would consider switching to FLTK, but not as a upgrade, more a downgrade ;). Though I only know the older FLTK, and not the newer one, so that one may have a lot more functionality. FLTK is written in C++, but you can use it from a C program, or at least you don't have to link to C++ libraries. If your goal is a reasonable fast browser, instead of a very fast one, then I'm afraid I won't use Dillo anymore :(. Looking at the test results, how alpha they may be, I can as well use Firebird. I have two computers, one 233 mhz and one 800 mhz, both are practical GTK2 free, and I would like to keep it that way. The great thing of Dillo is that it's so damn fast, where's the joy if you must wait 3 seconds before it's loaded? If the only reason to switch to GTK2 is to have better fonts support, then I would just stick to GTK 1 and use the freetype library directly, something along the line of prerendered fonts and use them as small pictures, whatever is fastest. Personally I don't need unicode support, can understand that there are a lot people that need or want it, but maybe it's not Dillo's task to support it, maybe a poll on the main website to ask the users about it? For me CSS support is much more important than most other features. I'm digging in Dillo's code to find out a nice way to implement https support, I think the current patch (besides that it's old) is unnecessary big and complicated, I think it can be implemented much cleaner, will post later more about it, probably asking how to handle the variables of the ccc function ;). Greetings, Indan

[Thanks Indan for your reply]

If the only reason to switch to GTK2 is to have better fonts support, then I would just stick to GTK 1 and use the freetype library directly, something along the line of prerendered fonts and use them as small pictures, whatever is fastest.

According to http://www.dillo.org/Notes.html, Gtk+ is seen as a mean to support Unicode, not as a mean to display "nice" fonts. But the issue of font rendering speed is also there and as you suggest, these can be optimized depending on context.

Personally I don't need unicode support, can understand that there are a lot people that need or want it, but maybe it's not Dillo's task to support it, maybe a poll on the main website to ask the users about it? For me CSS support is much more important than most other features.

Personnaly, I'd prefere Unicode support (or more precisely multi languages support), than CSS support. I personnaly do not browse only English web pages, and as the Internet is meant to allow information sharing throughout the world, I think Unicode and multi-language support is important. IMO, more important than CSS support, but I let developers decide which is more important and which is easier to implement and which will be implemented first, as each feature depend not only on user wishes but also on available resources. I think Gtk+2 is a nice library which is meant for ease of use and to fullfill most developers wishes in an easy way. This introduces some more abstraction and generalization in the way its widgets are implemented at the cost of specialized and optimized implementations. On modern hardware (>1Ghz, not like my 266Mhz chip), the slower than gtk1.2 library should still be quite usable (although, I did not test it on fast hardware). For example, the GtkTreeView: it is a very flexible widget and provides many features, but it is not a specialized widget anymore, so it is way slower than GtkCList or GtkCTree (AFAIS, it is not used in Thunderbird). Concerning Pango, it has to analyze each string to decide with which rendering engine the string will be rendered, this implies analyzing each character to determine to which language class it belongs, if there are RightToLeft and LeftToRight words etc... Each language may use a different set of fonts, and each font must be checked for its size. This computation is complex so to achieve fast rendering Pango should be studied carefully and rendering or drawing (on the expose events) algorithms should hand crafted. For example, maybe knowing that the page is in a certain non-unicode encoding, we could spare Pango some of its computation if Pango API allows such approach. So to summarize: I think porting Gtk+2 would need a quite deep knowledge of Pango and Gtk2 drawing pipeline and even more efforts on optimizations, as Dillo is meant to be a fast browser before being feature- rich browser. -- Melvin Hadasht

Jorge Arellano Cid wrote:

Hi there!

Hi!

At this point, having an FLTK-based dillo starts to be a very interesting option (especially after considering Owen's remarks, the pango issues, and the new expose model in GTK2 which adds a redesign stage for our progressive rendering).

Maybe someone that has gtkhtml2 installed can tell us how it compares with respect to the current gtk2 patched Dillo ? I can only experiment with Firebird-gtk2-xft, and I must say that the difference with the gtk1.2 version exist but it way smaller than the difference between dillo-gtk2 and dillo-gtk1. I experimented lately with mlterm, a multilanguage terminal with bidi-support and xft. It is currently slower than xterm+xft and has annonying flickers when scrolling. This makes me feel that the bottleneck will be mainly pango, the drawing path being more easily optimized with proper drawing algorithm. In my app, I had to create a special gtktreeview to have good performance and low memory usage on +1000 items. The optimization was done on the algorithm level and a bit also on the expose path.

Why did we want to go to GTK2? Mainly because of UTF-8 support.

To my eyes, there are two things that are important to allow most people access to Internet: Unicode support and Accessibility functionality. One advantage of GTK2 is proper Unicode support plus a Bidirectional algorithms and text layout and character shaping for many languages. Do you know if fltk2 has bidi support? I could not find any link about this. Another advantage is that when used with Gnome, GTK2 gains accessibility functionality for handicapped persons. I like to think that the kbnav is already one big step toward offering such functionality (perhaps it lacks a way to open context menus), thanks to Frank. But I must say I do not have any experience with Gnome and its accessibility functions.

Finally, from what I've seen, images can also be "handed" over to FLTK. Avoiding having to decode them into RGB, and manage them inside dillo (png.c, gif.c, jpeg.c, dicache.c, image.c, dw_image.c, ...).

Gtk2 comes with gdk-pixbuf. So you only need to pass it a file name or a pointer to a data.

This native FLTK images also provide an alpha channel so background images should be easy to implement too.

Do we really need alpha channel for background images? I mean, background images can drawn before foreground widgets, without the need for alpha channel.

I've been playing with fltk-1.1.4 for a while. It comes with a manual and lots of examples.

I played with version 2 from cvs, and it is amazingly fast. It is a shame that Gtk2 follows the inflation in resource needs like commercial products. -- Melvin Hadasht