KDE developer George Staikos recently announced that now KHTML uses a version of KJS that is nearly 100% in sync with Apple’s JavaScriptCore. Other portions of KHTML will be shared with Apple’s WebCore in the near future. This comes after a long and heated debate.
KHTML and Webcore Come a Little Closer
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I don’t understand why Apple was reluctant to open their repos earlier (yes, yes, they abided by the letter of the GPL, but dumped huge codebombs on the community instead of letting them track incremental changes) – it is clearly beneficial for both sides:
We are meanwhile merging patches back into their repository
as well. I have commit access to Apple’s repository and will be able to help
facilitate such work.
This is good news – and helps adoptation and recognition of khtml (Nokia for instance). We need that, because in the “alternative” browser space we have gecko … and we have gecko (and opera, which is closed source). Now gecko is slow – painfully slow, especially on older hardware. It is also said to be quite bloated codewise. Performance of khtml is superb on the other hand, and by all account (read Nokia’s announcment) it is one of the most elegant and compact codebase out there. Although I haven’t tried the new Opera preview, khtml recently certainly surpassed Opera 8.5.x version in speed (while maintaining very good performance on old hardware as well). I see KHTML as the most promising browser engine today. Perhaps after it is ported to QT4, we’ll see windows browsers built on khtml – that would be nice!
I modded you up but just had the question… is gecko really that slow? It is my understanding that gecko is actually fast but it’s codebase isn’t as refined and easy to work with as khtml. Are you confusing the beast of firefox with gecko the rendering engine?
Although it gets less obvious as you use newer computers, gecko does take longer to load than most other browser engines I’ve seen. Every browser I’ve tried on older hardware starts up much faster than gecko based ones, Internet Explorer, Opera, Konqueror you name it.
Take epiphany for example, you’d think that a program like that aught to come up in an instant and be blisteringly fast. But, because of the gecko rendering engine it still takes it’s time to start and the whole time you can hear your disk sapping.
On newer hardware the gap becomes smaller, but it’s still there and you can still tell. Gecko in comparisson to most other rendering engines takes longer to load.
PS. By load I am not referring to the time it takes to show a web site, but the time it takes for the actual rendering engine to load when the browser application is run.
what’s with threading in konqi on this site btw? I replied to your post specifically, and yet, my reply shows at the bottom, now both in konqi and FF
> what’s with threading in konqi on this site btw?
> I replied to your post specifically, and yet, my reply
> shows at the bottom, now both in konqi and FF
New posts always appear at the bottom. But the threading should not break (the reply counter should reflect the replies and the parent post link should be there).
I had examined the issue and reported a bug against Konq. A Konq developer came up with a workaround in a matter of two hours (nice to see the power of open source at work).
But:
1. The problem is caused by invalid HTML code on osnews that confuses Konq (so osnews would be able to do something about it *now* and *for everyone*. IMHO it’s a one-line fix!).
2. The Konq developer does not seem to be sure if his workaround should go into Konq code base.
3. Even if it went in that wouldn’t magically put the workaround into all the Konqs out there so many people would still be affected and many threads on osnews would still be broken in the future.
I reported this issue to the osnews staff several times, e.g. by email. I haven’t gotten any reply at all, not even a “we got your email but we won’t fix it”.
I’m slowly getting somewhat annoyed by this issue.
“I’m slowly getting somewhat annoyed by this issue.”
me too. they’re working hard on the site, that’s for sure, but i think they should reply to questions from their users… and many have been complaining everywhere – they just ignored it. if i said here eugenia sucks or tom-whatever, i’d get a reply from them, or they remove the post. so they obviously read the posts here… but if i aks if they can fix the broken OSnews code, they just pretend they didn’t see it, i guess….
ps i don’t think eugenia/whatever, actually i like osnews and their work, its just that its weird thei ignore users of the best webbrowser out there
I have only ever seen 4 emails about errors on the OSNews site regarding Rendering issues, all of which Adam has replied too, these are emails sent to the osnews staff via a mailinglist address, so all of us involved with OSnews get the emails.
Me, Thom, and David personaly have nothing to do with the backend of the site, and how it is coded, only Adam, and Eugenia deal with that aspect.
> I have only ever seen 4 emails about errors on the
> OSNews site regarding Rendering issues, all of which
> Adam has replied too, these are emails sent to the
> osnews staff via a mailinglist address, so all of us
> involved with OSnews get the emails.
I had sent the email to adam directly (adam at osnews.com) on 2005-12-30 and after not hearing anything from him (I thought maybe he was on vacation or the address was obsolete) I resent it to osnews-crew at osnews.com on 2006-01-06. I didn’t get any reply whatsoever. Maybe a too aggressive spam filter?
Gecko is quite slow.
I completed the test used to test script speed in the article you linked in one of your previous posts.
http://www.24fun.com/downloadcenter/benchjs/benchjs.html
Results were intereting. I did it twice with both konqi and firefox, each time clearing browser cache, and starting the browsers afresh. I chose “other” as OS (since FreeBSD was not in the list) and cpu speed 2-2.19.
Firefox – 21.1, 21.8.
Konqueror – 22.91, 22.97
(these are the the seconds needed to complete all test for each browser).
Which means that script speed – which was the only area where FF had a clear advantage (almost 2x as fast as konqi) is now very similar in each browser. However, there were interesting differences in how each browser performed in individual tests:
In the first test, firefox is much faster than konqi (at least 3-4 times faster), but in the 3rd test, this is reversed – konqi is ~3x faster than FF, while FF is again much faster in the 4th test. Konqi also beats firefox in 6th test (construct a phrase out of 50 different layers) by a fairly large margin, while FF is better in 5th and 7th. In the last test (7th) konqueror complained that the script on the page is freezing the browser, and asked me whether I want to quit or continue. I clicked continue, and the script finished succesfully.
I see KHTML as the most promising browser engine today
I don’t, sorry. Web page rendering is crucial these days, and KHTML is the worse between IE, Firefox and Opera, because web designers code badly.
maybe its right most webdesigners don’t take KHTML in account, but they will. safari uses khtml, and websites DO take safari in account…
+1 for Apple.
> +1 for Apple.
and for George Staikos and the other KDE devs working on this.
Does this mean web apps like Gmail might be closer to functioning fully under Konqueror?
depends on gmail… konqueror works fine with gmail, but not the other way around. if gmail detects konqueror, it sends faulty HTML (or the basic interface, i dunno) to konqi. if you set konqi’s useragent to safari, it works fine – so its clearly Gmail’s fault.
Will it be included in the next version of KDE?
sure, as kde 4 will take until the end of the year…
it MIGHT be included in kde 3.5.2, but not 3.5.1 (as 3.5.1 is almost ready).
Since it’s such a big change and some previous features are missing ATM (e.g. CPU guard), I’m pretty sure it will not be part of KDE 3.5.x.
Yeah, I wrote about it here: http://osnews.com/permalink.php?news_id=13175&comment_id=81682
Interestingly enough, firefox on windows seems to be a bit faster, but not by much. If you try FF (or other gecko based, supposedly “lightweight” browsers like Epiphany) on a celeron 300Mhz with 64 Mb RAM, you’ll see what I mean. In fact, FF is painfully slow on a 566Mhz machine with 64Mb ram.
But you can try to do a comparison yourself, even if you own modern hardware. The difference between gecko and other browsers diminishes with better hardware, but you can still note the difference if you run a cpu monitoring tool. Startup time is one thing, but you have to measure rendering speed. In order to do that, empty the cache of all browsers, than visit the same pages (preferably something that renders slowly, and doesn’t have stuff that requires plugins – if you measure on a flash page, you’re measuring the speed of the flash plugin, not the rendering engine… same with java applets) in all (all? I only compared to Opera and Konqi) browsers. They might render at same speed, but check how bigger are gecko’s CPU spikes! Now add to that the memory usage – and you’ll see what I mean. I notice this constantly because kcpuload is running and the OS doesn’t start swapping at all until I open up Firefox and a couple of tabs. And also notice that FF uses an 50Mb cache by default, while Konqi uses only 5Mb – and runs circles around FF in rendering speed.
I always have the impression, even if rendering speed is OK (as it should be on my desktop machine, a sempron 3100+ with 512Mb ram), firefox still feels kinda heavy – with or without about:plugins tweaks. It isn’t surpising at all that it didn’t enter the mobile browsing market (where Opera rules, and khtml gains ground thanks to Nokia).
FF is painfully slow on a 566Mhz machine with 64Mb ram
What can you expect with such hardware? I personnally would install OpenBSD on this machine and use it as a firewall. Nowadays, the minimum desktop configurations have 512MB. Mine has 1024MB.
I personnally would install OpenBSD on this machine and use it as a firewall
If you didn’t read the post I linked to – I did just that (well, FreeBSD instead of Open with Blackbox, opera, gaim, etc., and these machines are used as desktops, mainly for browsing the web and chatting)
His point was that you can see the gap more vividly if you watch it in action on older hardware, not that he uses old hardware for his desktop.
And I’ve used an older, slower machine as a perfectly capable desktop in recent years. I didn’t do whizbang multimedia stuff, but it was a fine desktop.
from
http://www.howtocreate.co.uk/browserSpeed.html
Konqeror 3.4.91 / Firefox 1.5
cold start 10.84 / 9.64
warm start 1.23 / 3.95
css 0.72 / 1.72
tables 2.97 / 2.53
script 77 / 24
images 2.11 / 1.92
history 48 / 57
This information is what made me question what you were saying.
Well, interesting results.
What I wrote was my experience on multiple computers running multiple OSes. Firefox (and gecko based browsers in general) are noticably slower, though if you throw enough cpu cycles and memory at FF, it comes pretty close, but the difference is still visible. As I said numerous times, the lower you go (hardware-wise), the more obvious gecko’s relative slowness becomes. What makes this chart interesting is that except for scripts, konq 3.2 beats ff in every test, or it is rather close to firefox (multiple image rendering). As far as speed goes, it is second after opera. You quote the 3.4.91 results – I’m not sure if those are reliable, since 3.4.91 must have been an (how much early?) development version. Who knows what debug codes were still present? Firefox wasn’t final either (beta2), but I think it was closer to final than 3.4.91. Everyone who have used KDE for a long time would tell you that Konqi that comes with kde 3.5.0 is definitely faster than konqi that came with 3.2.x. And seeing how konqueror 3.2.x is the second fastest browser after Opera (if you take an overall assesment – it is much slower with scripts, I see that), my assesment that konqi now beats Opera in speed might be correct actually.
This is simply how it feels from the time I began using konqi more regurarly. I used it occasionally since 3.0.0, but it became my main browser from 3.4.0, when webpage compatibility reached a reasonable level. Ironically, osnews is now the only site (from those I visit) that has problems in konqi (something with thread views), so I use FF to post this. 1.5 was slow in comparison to Konqueror 3.4.3. From what I can tell, konqi that comes with kde 3.5.0 has become even faster (both rendering speed and the interface – it is important to know what we actually measure), so the gap should be even wider. The test you linked to doesn’t disprove my claim. I can’t comment on konqi 3.4.91 – but since konqi is my main browser, it has always been faster and consumed less CPU to render the same page than firefox – and according to the test, it was quite speedy from at least version 3.2.x
– well, except for scripting, which brings as back to the topic at hand: KJS, and how nice this new cooperation between APPLE and KHTML devs is 
)
ps. It is important to note that I view and edit tables many times on this site (or at least I did, now I find less and less time to do that): http://www.tftpanel.hu/index.php?topic=monitortablazat
Now if you check the test results, konqueror 3.2’s table rendering is almost twice as fast as FF’s (and the 3.4.91 results are absolutely meaningless – it is just not what I experienced with 3.4.3 or 3.5). So to me, FF might seem more slower than to others – it is only fair to mention this. The big difference is not with rendering the table actually, but when I edit it (after logging in). I’m not sure which aspect of the browser is used to present the textbox (similar to this one btw) full of html code and some javascript, but it is definitely slower in FF, by a fairly large margin.
For anyone interested in getting the WebCore/WebKit code:
http://webkit.opendarwin.org/
(Check the blog for progress reports, like the status of SVG suport: http://webkit.opendarwin.org/blog/ )
I have written some ajax applications that do not work with konqueror, but with gecko based browsers and iexplorer.
Should this mean great news for people like me and other?
I think so. I hope so!
Not exactly. When Konqueror is detected we get the basic HTML site, when we spoof as Safari they send us some JavaScript that doesn’t work 100%.
The trick is to spoof as Firefox because the Firefox version of GMail works perfectly in Konqueror.
Is this documented somewhere? I still assumed that spoofing as safari was the way to go for konqueror + gmail. Thanks for the info anyway
(posting this from Firefox until osnews fixes the “replies don’t appear below parents in konqi” issue that apparently you ran into as well)
Ahh, never commited the fix because of the 3.5.0 freeze.
Replies on OSNews will thread in 3.5.1
> Ahh, never commited the fix because of the 3.5.0 freeze.
> Replies on OSNews will thread in 3.5.1
Thanks. 🙂
Still, I think OSNews should move the hidden field or the “<p>” tag.
You can use konqueror with gmail just fine, just change your user agent for “mail.google” to read as firefox, then the first time you log in click “Standard View” or something at the top of the webpage. Not perfect view, but fully functional for me with kde 3.5
My konqui 3.5 lets me set the ID to Safari 1.2, but that doesn’t fool Gmail.
I haven’t found a sight that isn’t readable in konqueror yet, atleast with the newest version. Maybe a sign that all that hardwork by the khtml folks (I really do enjoy this browser by the way, if one of you is reading), apple, and move towards web standards is really working?
Edited 2006-01-12 15:35
I think that it is somewhat quite good that web browser renderine engines (and Javascripts , css, …) are merging.
As a web developper it will cause so much less trouble … And we won’t need a Mac to test with safari, as long as Konqueror is rendering in the exact same way.
Keep up the good work !
——
GavrocheLeGnou
http://palabre.gavroche.net
Despite other speed-ups I still see significant improvements in Konqi’s rendering speed by setting
export KDE_NO_IPV6=true
I wish the KDE guys would find a way to auto-detect whether ipv6 is actually used or not.
Quote:
“My konqui 3.5 lets me set the ID to Safari 1.2, but that doesn’t fool Gmail.”
I tried it with the id set to Safari 1.2 and it didn’t work correctly.
If you set it to Firefox 1.0, it’ll work ok.
The Gmail issue is documented both in my blog and in the GMail bug report.
Seems replies here are broken again… I already fixed that once by adding work-arounds to OSnews faulty forms in tables. We need more OSNews specific work-arounds I guess.
sorry, i was a bit harsh – but i wasn’t talking about an email from me, as i didn’t mail you guys… mostly because i couldn’t really imagine it wasn’t noticed.
anyway, i hope this gets fixed, it would make the osnews experience a lot better…