-- En reponse de "RE: [Dillo-dev] FLTK" de Eric Gaudet, le 14-Oct-2003 :
I will give it a try.
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
Ok, here are the numbers. But first, the test procedure. I did a fresh cvs checkout twice, and applied the patch to one of them and compiled both. I named dillo1 the one using gtk-1.2 and dillo the one using gtk-2.0. The only difference between dillo1 and dillo2 is the gtk version they use, everything else is the same (internal representation of the page widgets) I'm running debian testing and I updated my system just before the test today: gtk 2.2.1-6 and pango 1.2.5-1. My machine is a Toshiba 3020CT laptop, Pentium-MMX 300MHz with 64MB ram First run: ---------- I tried to render the front page of tigerdirect.com, which should represent a fairly common page design. First, I download the page and the images with 'wget -kp http://www.tigerdirect.com'. index.html is 66kB and it loads 30 gif and 23 jpg images. I loaded the page with both dillo1 and dillo2 with the command 'time dillo1 index.html'. I exited dillo shortly after the loading and rendering were completed. The idle time after rendering is not included in the results, nor is the system time used to actually load the page: I'm only giving the user time, which is the cpu time the application used. I'm also not giving the real time for this run, since it depend on the average cpu load, the memory swapping, etc, and would need a much more elaborate benchmark to be significant. For the memory usage, I used pmap on the dillo process, and added only the anonymous pages (mallocs). For each browser, I ran the test once, disregarding the time (to let buffering occur), then several times and calculated the average time. Results: time1 time2 delta/30 prps mem(KB) dillo1 1.36s 1.82s 15ms 67 2516 dillo2 3.10s 6.90s 126ms 8 3624 Legend: - time1 represent the time for starting the browser, wait for rendering to complete, and quit. - time2 represents the time for starting the browser, wait for rendering to complete, then press the pagedown key twice, then the pageup key twice, for a total of 30 redraws of the page, them quit - delta/30 is the difference between time2 and time1 divided by 30. This is the time to redraw the page. - rps is the number of page renderings per second: this is 1/(delta/30) - mem is the memory usage in KiloBytes. Conclusion: The starting time is longer for dillo2, but not too by much and I think I could live with it. Scrolling through the page is noticeably slower, with a significant delay between the clicks or key presses and the actual redraw. dillo1 is always snappy and blazing fast, even when dragging the page with the middle button. dillo2 feels heavy and slow, and it's hard to drag the page around, since the page display is following the mouse movements with a delay. Second run: ----------- For this run, I wanted to render a very large page. I used a 2.5MB html file without images, and only a few tables, displaying 7300 lines of mixed bold, italic, regular text and 2 links for each line. Results: time1 time2 dillo1 13.2s 14.2s dillo2 n/a n/a Legend: - time1 represent the time for starting the browser, wait for rendering to complete, and quit. - time2 represents the time for starting the browser, wait for rendering to complete, then press the pagedown key to scroll all the way down, then quit Conclusion: dillo2 could not complete this test: after a few minutes it started swapping like crazy and used all the memory and cpu. I had to kill it. I aborted this test and did not do mem usage. 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 Legend: - time1 represent the time for starting the browser, wait for rendering to complete, and quit. - time2 represent the real time for the same operations. I quit the window as soon a the page finished to load (the top-right box was grayed-out) - mem is the memory usage of the page. Conclusion: I like to use dillo to display documentation, and when I do that I always choose the "all in one big page" link, because I know dillo will swallow it without complaining, and I will be able to scroll through it to find what I need. With dillo2, I don't feel confident doing that anymore. Fourth run: ----------- This is the start time test: just display the start screen to see the mem usage. I did this test only because of the failure in the second run. I wanted to know more about the scallabilty issues of dillo2 and I needed a starting point. Result: mem(KB) dillo1 944 dillo2 2148 Conclusion: Dillo2 seems to use much more memory than dillo1 for pure text rendering. Image and other widgets seem to use the same amount of memory. Overall, displaying the same page in dillo2 needs 2 to 3 time more memory than in dillo1. Fifth run: ---------- This is a free run of internet browsing, to get an overall feeling. No numbers for this one. Conclusion: This test confirms the feeling I had throughout this test: dillo2 feels slow and everytime I scroll I find myself waiting the the page to redraw. Maybe I'm just used to dillo1's speed. During my every day usage, starting dillo1 is as fast as starting vi in a console, and you're merely displaying a text file for free. With dillo2, you really feel like you're starting an *application*: it needs a (small) investment (of time) every time. This is a different feeling. Also, I thought the main goal of dillo2 was to display unicode characters. I tried to display asian characters, but I had the same result as dillo1. Is this not coded yet? I though it was free with pango. As for the rendering itself, I must admit that anti-aliasing is nice. Kinda blurry but nice. But the characters are much larger than in dillo1: I had to use font-factor 0.8 for dillo2 and 1.2 for dillo1 to have the same texst height. Final conclusion: ----------------- I don't think I want to give up dillo1's speed for a marginally better rendering. I understand there are asian-fonts patches out there, maybe we could include them as a compile-time option. Being able to render very large documents without dragging the whole system down is also a big plus for me, and dillo2 really disapointed me there. Best, Eric