KDE developer Zack Rusin announced in his blog he just committed the QT Mozilla code. To start testing it, all you need to do is checkout mozilla, configure with –enable-default-toolkit=qt, and launch make.
Mozilla finally KDEfied
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Does this mean anything for firefox as well or will this only affect normal Mozilla? I have no knowledge on how the two projects relate, so sorry if this seems an unintelligent question.
im suprised this didnt happen ALOT sooner considering how many people use kde and mozilla.
i’m not. gtk has a multitude of advantages over qt for porting a linux app. i’m sure the barriers were rather large, why else would it take so long?
The initial port was done by Lars Knoll and Zack Rusin in four days during aKademy. This is a testament to the portability of the Mozilla framework, the maturity of Qt, and the skill of those involved. The reason why it took so long to this point is mainly a lack of developers interested in doing a Qt Mozilla port, given the existance of KHTML.
i hope Konquere remains KHTML and not geko
I don’t suppose this means we could concievably see a moz-type thing ported over to QT/Embedded frameworks, like OPIE and QTopia, does it?
Konqueror will support <bold>both</bold> KHTML and Gecko. Distros might though use Gecko by default.
http://www.kdedevelopers.org/node/view/615
Does this mean anything for firefox as well or will this only affect normal Mozilla?
Yes, as you can read in the link posted by Syzar:
Does it mean Firefox will run natively on KDE? Yes, that’s essentially exactly what it means. We haven’t only ported the Gecko but we wanted to make it as complete as possible. I do want to make Firefox a great browser for KDE users. In the coming weeks I’ll be integrating KIO, KWallet and KCookieJar so I’m hoping we’ll see more great things soon.
Maybe i’m missing something here, but the other day i gave Konqueror a try again (haven’t used it in a year or two) and the rendering of tableless-layout with heavy-css-usage sites was pretty bad. Well, very bad.
I notice people here want to keep the kthml engine, is there any specific reasons why, instead of using the gecko engine that is. I’m really interested, not trying to flame it. I just wonder what the benefits of using the khtml engine are?
I just wonder what the benefits of using the khtml engine are?
The main reason I’m using KHTML is that it’s VERY fast compared to Gecko, and almost on par with IE. Beside that, it nicely integrates with the rest of my KDE desktop, and it has some nice features like spell-checking almost everywhere. The only thing I miss from Firefox are some of its extensions, like Adblock, but I recently discovered Privoxy and I’m happy with it.
Fully agree. Porting Mozilla to KDE is a true “tour de force”. I hope this project continues.
Try running Gecko on an AMD K6-2 450MHz, it can happen, but it runs oh sooo slooowww.
KHTML on the other hand blazes, and loads (guesstimating here) 96% of sites perfectly.
Unfortunately the Gecko KPart has not been committed yet.
The feeling of heaviness. Gecko feels heavy, KHTML doesn’t. Sure, there are things that KHTML needs to fix, but generally speaking I can work and test in KHTML with a general expectation that it’ll look the same in Gecko. In some ways Gecko remains superior, but the differences are getting smaller with every release.
Some people like to make mountains out of molehills with regards to differences between Gecko and KHTML rendering. Some people will make a big deal out of the differences between dihydrogen monoxide and Hydroxic Acid.
On a codebase level KHTML is smaller. Imagine dropping KHTML and being stuck with gecko even for embedding into Quanta Plus previes, or KHTML, or akregator. I shudder to think of such things.
Now to some speculation. With the addition of Windows compatability code to KDE libraries KDE apps have the ability of being made Windows portable, hypothetically at least. Perhaps sooner rather than later we’ll see a Windows browser based on KHTML. Which should bring even more developers to hack on KHTML.
A while ago I saw a post by a mozilla developer deriding the lack of a capability in KHTML and made some belittling comment about ‘superior architecture indeed’. Now I am not a programmer, yet, and I don’t know squat about either the Gecko nor the KHTML codebases, but it does not follow that since project A does not have a feature project B has that project A has worse architecture than project B. In the case of project B, Gecko, they have more developers to hack that KHTML does, as well as more testers, that in of itself goes a long way to making Mozilla browsers more full-featured.
Well, I think part of the slowness feeling with firefox on linux is gtk’s fault. I find gtk generally more sluggish and less responsive than qt, at least on linux, so this is goos news indeed.
On windows, firefox is imo faster than ie (except launching it, that takes a few seconds), so I think it’s more than up to par with ie already.
Quote:
“Maybe i’m missing something here, but the other day i gave Konqueror a try again (haven’t used it in a year or two) and the rendering of tableless-layout with heavy-css-usage sites was pretty bad. Well, very bad.”
@tobbe,
Can you give the url’s of those sites please?
And maybe also run them through a validator?
In most cases, browser engines are blamed for amateuristic websites that don’t follow standards.
Well, I think part of the slowness feeling with firefox on linux is gtk’s fault.
Yes, I think so too. Anyway, it’d be interesting, once Firefox/Qt will be out and stable, to compare it with its Gtk counterpart, just to see if it is really Gtk’s problems that give Firefox the feeling of being heavy.
“Well, I think part of the slowness feeling with firefox on linux is gtk’s fault.”
To a degree, I agree but Gecko is a behemoth on any platform in my experience, especially with memory. This is accentuated on low-end hardware.
I notice people here want to keep the kthml engine, is there any specific reasons why, instead of using the gecko engine that is. I’m really interested, not trying to flame it. I just wonder what the benefits of using the khtml engine are?
KHTML is way faster, smaller, and easily portable than Gecko and now it has Apple standing behind of it and it’s developing lightning fast speed. Do I need add more?
So the summary of the above comments:
(1) Khtml is quicker than gecko.
(2) On heavily formatted sites gecko gives a better result.
(3) KDE want to support both since people’s requirements vary.
Assuming setting the option isn’t too obscure (you may smirk here) what *is* the problem?
As you rightly imply, there is none. Integrating gecko into kde is just positive. However did the absence of a problem ever stop people from starting senseless kde vs gnome / qt vs gtk flamewars?
There isn’t one but people like to argue their “point” even when nobody is listening to them and just want people to hear their own point.
Has anybody screenshots ? How does it look like ?
Errr… you’re kidding right?
I smell FUD. GTK+ has nothing to do with Firefox’ slowness on Linux. And neither Firefox nor GTK+ is SLOW! Last time I checked, yesterday, Firefox was still a faster and better renderer than Konqueror is.
This GTK+ is slow propaganda is really bordering on stupidity, frankly.
Not true. I run both Linux and Windows on the same box(800Mhz Duron, 256MB ram).
On Windows, Firefox is definitely faster – it renders pages faster and it responds to UI events faster than it does on Linux.
I love firefox. I use it all the time, but given that I have a far better browsing experience using Firefox on Windows (XP or 2000) I stick with Windows.
Ok, so this may be pretty subjective, but reading the other replies, I’m not the only person to have noticed this.
The combination of Konq with Geckho should give me all that I need..unless someone rewrites Firefox to use QT rather than GTK+….
KHTML is way faster, smaller, and easily portable than Gecko and now it has Apple standing behind of it and it’s developing lightning fast speed.
From what I’ve read from KDE developers that’s not really true. Apple develops it’s own codebase and does not check in in the KHTML/KJS-CVS (but the source is still open of course). It’s more like a forked project.
It’s quite difficult to take over the changes Apple made.
Not true. I run both Linux and Windows on the same box(800Mhz Duron, 256MB ram).
On Windows, Firefox is definitely faster – it renders pages faster and it responds to UI events faster than it does on Linux.
I can confirm this. Even on my Athlon XP 2000+, Firefox is much slower on Linux than on Windows XP. It also have this ages old menu mouseover bug. Move the pointer slowly between your folders in your bookmark menu and you’ll see that the mouseover effect sometimes disappears between folders. Anyone, please fix this.
Not true. I run both Linux and Windows on the same box(800Mhz Duron, 256MB ram).
On Windows, Firefox is definitely faster – it renders pages faster and it responds to UI events faster than it does on Linux.
Yes, Firefox is faster in Windows. But does GTK+ have to be the reason? In my experience GKT+ itself is pretty darn fast.
Firefox is slower in BeOS too. But it can’t have to do with GTK right?
I can confirm this. Even on my Athlon XP 2000+, Firefox is much slower on Linux than on Windows XP. It also have this ages old menu mouseover bug. Move the pointer slowly between your folders in your bookmark menu and you’ll see that the mouseover effect sometimes disappears between folders. Anyone, please fix this.
I had this problem with the Plastik theme. With the standard theme it was gone.
But Firefox is still a bit slower and less responsive with Linux (Fedora Core 2, KDE 3.2) than with WinXP on my PC (Athlon XP3200, 1GB RAM). Konqueror and Opera are much faster than Firefox on Linux.
Umm, KDE devs have their own requirements for code cleanliness. From reading some of the mailing lists, or just lurking amongst some of the devs I got the impression that some of the Apple code was just not clean enough for the devs.
Another thing to keep in mind is that Apple is probably only required to release the code whenever they have a new release. So they could be writing a whole bunch of modifications and releasing code on a much slower basis than KDE since KDE has fairly steady releases. Mind you, I don’t actually know how often Apple sends back code to KDE. Last but not least, the KHTML devs are few, and integrating Apple code can take time depending on what exactly they did.
FC2 just a big monster both kde and gnome just become faster and lighter in there lastest release . there is no reason for the exaggerated requirements of fc (e.g look at mepis reuirement) , but still firefox slower on linux (you know apple and oranges thing ).
I confirm also the extreme slowness of Firefox on Linux compared to Windows. Well I’m sure Gtk is responsible in
part for that, but also I think the other cause is that Firefox devs have warned that they were concentrating
on Windows first as a platform. Qt will undoubtedly make
things a little better. At the very least it will save some RAM. I’m using the Gtk_Qt Engine which makes things worse. But soon I won’t be needing that anymore for Firefox. Furthermore, KDE 3.3.1 will include great speed-ups for the Plastik theme which should help as well.
About KHTML in my experience is much faster to start, but
it renders much slower than Firefox.
Yes, Firefox is faster in Windows. But does GTK+ have to be the reason? In my experience GKT+ itself is pretty darn fast.
Firefox is slower in BeOS too. But it can’t have to do with GTK right?
Well, the reason it’s slower on beos doesn’t have to be the same reason it’s slower on linux.
Does it have to be GTK’s fault ? Certainly not. But I do believe it is, at least partially.
I generally find GTK apps to be noticeably slower than qt ones on linux. Rarely “goddamned, unbearably slow” (except linux eclipse, but it has probably problems on it’s own), but more “slightly annoying slow”.
I also find that GTK seems to be faster on windows than on linux.
It’s only a subjective impression regarding gtk performances. I have nothing against GTK, and I have no agenda or interest in people not using gtk, or some interest in people using qt, therefore it’s not FUD.
Negative impressions about something doesn’t always have to be FUD.
my current experience for Firefox speed is :
beos 1st (private build w/o debug symbols)
linux, windows 2nd (don’t see “human noticable” difference…
but it could depend of profiles size and addons etc…
By example, the loading is faster under beos than windows or linux. Another start is faster under Linux (good caching).
For page rendering, it’s quite the same with a feeling that it’s faster under BeOS…
I have been using a wrapper for GTK for a while now, which translates GTK to QT for use with KDE. It works well but can be slow. Worth it for the consistant look though. A native port will be very nice.
The reason why Firebird is probably Gtk. I remember the same problem Eclipse Gtk had/has. It is related to too many repaint events, as far as I can remember. For more information, browse eclipse bugzilla. Some issues where fixed, but still, Windows version is faster. Programs not connected to Gtk (like MySQL or GCC) are generally cca. 10% faster on Linux.
Will you all stop! The GTK+ flags on Linux are optional. I have used Firefox with and without the GTK+ and GNOME flags on Linux and there is absolutely no difference, except in looks, between it’s behaviour on Linux or its behaviour on Windows with regards to rendering speeds.
I have no witnessed any measured slowdowns in rendering speed either at the widget level or at the parser level with Firefox on Windows or on Linux. In fact, I can hardly tell the difference.
You people act as if Firefox takes ten minutes to render google.com on Linux and … oh… it’s because of GTK+. Yeah, because we all know GTK+ is a web rendering engine.
This has got to be most ridiculous comment all year. People don’t even know the relationship between a widget toolkit and a web parser.
The funny thing is some of you on KDE don’t even have Mozilla compiled with the GTK+ flag on. So how on bloody earth is it an issue with GTK? And what again is the relationship between GTK+ and Gecko with respect to rendering speed?
Sheesh! I give up.
Will you all stop! The GTK+ flags on Linux are optional. I have used Firefox with and without the GTK+ and GNOME flags on Linux and there is absolutely no difference, except in looks, between it’s behaviour on Linux or its behaviour on Windows with regards to rendering speeds.
What flags ? As far as I know, the only widget toolkit that mozilla could use on linux until now has been gtk. (see http://lxr.mozilla.org/seamonkey/source/widget/src/ )
You people act as if Firefox takes ten minutes to render google.com on Linux and … oh… it’s because of GTK+. Yeah, because we all know GTK+ is a web rendering engine.
I’m sorry. I omited to specify in my other posts that I was talking about the overall reactivity of the interface, not the rendering speed. The rendering speed is good. Reactivity, as for instance the perceptible amount of time between the time you click the mouse right button and the pop menu show up, isn’t in my opinion as good as with qt apps, or as good as under windows.
Calculating dependencies …done!
[ebuild R ] net-www/mozilla-firefox-1.0_pre-r2 -debug +gnome +gtk2 -ipv6 -java* -ldap -mozdevelop -moznoxft -mozxmlterm +truetype -xinerama +xprint 0 kB
—————————————————–
If you look closely, Firefox can be compiled with several options turned off or on. I have successfully compiled firefox without the gtk and gnome flags turned on(i.e without support for GTK) and there is no difference, except it looks a little ugly.
Last I checked, XUL Mozilla’s widget toolkit is cross platform and theoretically, it should be slower than GTK+ or Qt, since it uses a combination of CSS, Javascript and XML for displaying widgets. In reality, XUL does quite well.
With regards to GTK+’s “slowness”, I say it’s a combination of bandwagon perception, myth and other pyschological related effects. You have it ingrained in your mind that GTK+ is slow, because every other person on OSNEWS told you so without substantial or credible evidence.
The reality is that GTK+ is very responsive. In fact, more responsive than my Windows XP box. It may render text slowly, because pango has a complex method of displaying text to support multilingual caligraphies. It has resive problems too. But all the OS toolkits I have used including Qt suffer from this problem with the exception of Windows. GTK+ and Qt both suffer from resize issues. Yet, I don’t see anyone clamoring Qt is slow.
Finally, on responsiveness, GTK is very responsive. If it isn’t responsive on your end, I am betting something is totally borked on your box, or you have one of those slow distros installed. Heck, I even checked out Ubuntu’s GNOME 2.8 liveCD, and it is the most responsive and fastest LiveCD I have ever used.
I don’t have a rig for a machine either. I run Linux on 1.4 GHz Athlon CPU with 256MB of RAM, and GNOME and GTK apps including Firefox is plenty fast. In fact, Linux is a lot more responsive on this box than Windows XP with the latest service pack. And even friends have confirmed this.
So, I’ll say it again, without substantial, credible and overwhelming evidence, let’s stop this GTK+/Firefox/etc is slow mantra. It’s retarded and polluting an otherwise nice thread. Because Qt may now use Gecko wouldn’t automatically make it faster than Firefox. Heck, Epiphany and Galeon which use pure GTK+ around gecko aren’t any faster than Firefox.
In fact, until this OSNEWS “GTK is slow” propaganda began, not too long ago, almost anyone would tell you that applications launch a lot faster in GNOME/XFCE/ICEWM which all use GTK+ and are more responsive than the KDE/Qt counterpart which take forever to launch, and up until the 3.1 series where slow. The KDE team put a lot of effort to optimizing many KDE for the 3.2 and 3.3 series and now things are much improved.
But this GTK+ is slow argument just needs to stop. It’s especially annoying when it is being fling about with absolutely zero credible evidence or facts. Every gives their own ‘feelings.’ And quite frankly, no developer gives a damn about feelings. They want reliable information if at all they are going to fix GTK’s ‘slowness’.
The last comment was directed to MORB by the way.
I think someone here needs to get away from his computer for a while. It’s only software.
@Mystilleef
Excerpt from mozilla-firefox-0.9.3.ebuild:
IUSE=”java gtk2 ipv6 moznoxft truetype xinerama”
RDEPEND=”virtual/x11
!moznoxft? ( virtual/xft )
>=sys-libs/zlib-1.1.4
>=media-libs/jpeg-6b
>=media-libs/libmng-1.0.0
>=media-libs/libpng-1.2.1
>=sys-apps/portage-2.0.36
dev-libs/expat
app-arch/zip
app-arch/unzip
gtk2? ( >=x11-libs/gtk+-2.1.1 >=dev-libs/libIDL-0.8.0 )
!gtk2? ( =x11-libs/gtk+-1.2* =gnome-base/orbit-0* )
java? ( virtual/jre )
>=net-www/mozilla-launcher-1.7-r1″
As you can see, it does depend on gtk. If you have the gtk2 use flag, it’ll use gtk2, otherwise it’ll use gtk 1.2, hence why it looks a little different.
Last I checked, XUL Mozilla’s widget toolkit is cross platform and theoretically, it should be slower than GTK+ or Qt, since it uses a combination of CSS, Javascript and XML for displaying widgets. In reality, XUL does quite well.
Well, duh, extra layers slow things down, I know that, thanks. It doesn’t explain why firefox feel faster on windows, although of course, it can be argued that other factors than just the widget toolkit may weight in.
With regards to GTK+’s “slowness”, I say it’s a combination of bandwagon perception, myth and other pyschological related effects. You have it ingrained in your mind that GTK+ is slow, because every other person on OSNEWS told you so without substantial or credible evidence.
No. I haven’t been reading osnews for that long, and I don’t even remember any specific “gtk is slow” comment, although yes, I probably read some. I noticed gtk was generally slow on my own. I had first installed gnome, wasn’t impressed by the lack of reactivity feeling, and then only installed kde. I’ve probably read “kde is bloatware” about as often as “gtk is slow”, actually.
Because Qt may now use Gecko wouldn’t automatically make it faster than Firefox.
That would be the other way around. Gecko using qt.
Heck, Epiphany and Galeon which use pure GTK+ around gecko aren’t any faster than Firefox.
I don’t see how this particular argument helps your point.
Finally, on responsiveness, GTK is very responsive. If it isn’t responsive on your end, I am betting something is totally borked on your box, or you have one of those slow distros installed. Heck, I even checked out Ubuntu’s GNOME 2.8 liveCD, and it is the most responsive and fastest LiveCD I have ever used.
Well, it seems we’re both running gentoo, so no, it’s probably not that. And I don’t see how a configuration problem would make qt be faster than gtk. Especially since I use the default gtk theme, which is very lightweight, and keramik on qt, which uses bitmaps all over the place.
Yes, I know it’s not helpong. As I stated, it’s a subjective impression. I don’t bear slugginess in an interface too well, other people may be more tolerant than me. It’s not the problem, I guess my original point was that I think firefox may run better on kde, and there’s really no use in debating it any further until we’ve seen how it runs.
http://www.osnews.com/comment.php?news_id=7953
Personally I never found gtk to be particularly slow, however there seem to be some speed problems with gtk that are even acknowledged by those involved with the project.
Anyway, this is about KDE and Mozilla and not about gtk right or wrong.
In fact, until this OSNEWS “GTK is slow” propaganda began, not too long ago, almost anyone would tell you that applications launch a lot faster in GNOME/XFCE/ICEWM which all use GTK+ and are more responsive than the KDE/Qt counterpart which take forever to launch, and up until the 3.1 series where slow. The KDE team put a lot of effort to optimizing many KDE for the 3.2 and 3.3 series and now things are much improved.
I also think gtk is slow. Qt fells a little bit faster (but this is only my opinion. I also said a little bit, so please don’t flame for it, I’m not willing to read something that start with : “but gtk…”).
UI wise windows _feels_really_ faster. I’m a linux user, and I really prefer linux over Windows. And this also allways been so. But I had to accomplish some work on windows, and so I had to use Windows2000 last weak. Of course I missed my shell
. But see : It’s reaaly faster. Even gaim starts faster. With nvidias tools I turned on the option “see the contents of windows while moving them”. And this is also _so_damn_ faster. widgets are faster …
So … I know, this really hearts, for us people wanting to promote opensource. (I want also, I’m also putting everything I develope under opensource license.).
But see, something here is terribly wrong. And I dont really think, this is because of QT/GTK, thought, I’m not sure of that. I guess, it has something to do with the X-server. renicing it made my system unstable. So … does someone know what the problem is?
My ideas :
[ ] Kernel latency ? (Windows uses a kernel that is really optimized for desktop)
[ ] The X-Server ? (To slow … There is a linux distribution called Athena, which uses a closed-source X-Server. I tryied it, and is really _feels_much_much_faster_
[ ] Need of accelerated 2-D rendereing ? (like under OS-X)
Also start the screensaver “Deluxe” from xscreensaer. Do you see how slow it is ? this is what Jamie Zawinsk wrote in his documentation :
“This draws a pulsing sequence of stars, cirles and lines. It would look better if it was faster, but as far as I can tell, there is no way to make this be both : faster and flicker-free. Yet an other reason X sucks. Written bye Jamie Zawinski”
So … If you know other reaons, why rendering is slow, append it on this list.
And I didn’t say that to offend someone. Of course, this are things that can be improved, (Im looking forward for X.org, Cairo, and more lantency patches for the kernel)
HelloWorld
The problem is people throwing the word faster/slower, responsive/sluggish around. When you say Qt is faster than GTK, by how much? I’m I supposed to agree with your perception or opinion?
When you say Firefox is faster on Windows than it is on Linux, what exactly do you mean? Do you time how long is takes to launch Firefox on both boxes? Do you measure this supposed responsiveness in a verifiable manner? Or is this also perception?
It’s pretty pointless arguing on perception because everyone has their own perceptions. But when someone publicly claims something is slow or fast, it is natural expect some credible evidence or verified sources.
Otherwise, we all become SCO screaming they own Linux without any evidence. That’s why I yelled FUD earlier. Or it becomes a my father can kick your father’s butt contest. Everyone is entitled to their opinions, it’s when they start disguising them as facts, that it becomes worrisome.
Sure GTK+ has issues, but when you say it is slow, I respect your opinion, but again I disagree with it.
OK, if you want to know why Gtk is slow in great detail, go to Eclipse Error -> Bugzilla -> Error 37683
For me, Firefox under Windows take about 3 seconds to start up, under Linux it takes about 10 seconds. Subsequent start-ups take less, about 4 seconds. I can’t comment on UI responsiveness because I’m using GTK-Qt.
I’m also not going to comment on whether GTK is to blame. I’m not a programmer so I don’t know. But I’m just confirming that Firefox under linux is slower.
Back on topic, intergrating Qt into Mozilla is fantastic, it makes Mozilla far more usable under KDE. And <strong>that</strong> is what this is all about.
At the moment this is not more then a window displaying webpages, you can click links but there is no other kind of navigation.
The problem is people throwing the word faster/slower, responsive/sluggish around. When you say Qt is faster than GTK, by how much? I’m I supposed to agree with your perception or opinion?
No, you’re not. I don’t think I implied otherwise.
It’s pretty pointless arguing on perception because everyone has their own perceptions.
I didn’t even intend to argue about it in the first place, although I knew it would probably happen anyway.
Everyone is entitled to their opinions, it’s when they start disguising them as facts, that it becomes worrisome.
I have been careful to use “imo”, “I think that”, and other similar idioms each time I mentioned the slowness I perceive about gtk in my earlier comments, so I don’t see how possibly it could have been taken as I was disguising my opinions on the matter as facts.
Sure GTK+ has issues, but when you say it is slow, I respect your opinion, but again I disagree with it.
Which is how it’s supposed to work.
@HelloWorld82
Windows employs a lot tricks to decieve users into thinking apps are fast. For example, Firefox launches faster on Windows on my box because Windows precaches it in memory. So when you close the Firefox browser, it is not really closed, it is still in memory. The next time run Firefox it will appear almost instantaneously.
When it comes to menu operations, running multiple applications concurrently, and memory intensive tasks, Windows will crap out very easily. I have bookmark containing 10 websites. Under Firefox on Window, launching all those websites simultaneously in tabs, will lock up Windows for a few seconds. That is, I can’t use the mouse, I can access menus, I can’t do nothing for a few seconds. That is just not visible on Firefox on Linux, well at least on my system.
Linux just doesn’t employ as much tricks as Windows and Mac OS X do to illude users’ senses. OS X has a slow and resource intensive UI. Yet you’ll hardly here any complaints about how slow Aqua is. That’s because the Aqua developers pay a lot of attention to smooth rendering, rather than fast rendering. Linux renders very fast. It’s just not as smooth, well timed and well coordinated as OS X or Windows. If one part renders faster than another part of a widget, users will think the app is jerky. If one part renders slower than another widget, users will think it’s slow.
Finally, X is very fast at rendering. Even faster than Windows. But nobody uses X’ toolkit because it is inadequate for mordern needs. Cairo et al will help to make rendering smoother on Linux. I doubt it will make things render faster, if indeed speed is an issue with regards to rendering on Linux. I don’t think we should aim for fast or slow. Instead we should aim for well timed, well synced and smooth UI operations.
The problem isn’t rendering speed, and unless your hardware is really old or you’re using unaccelerated drivers, the problem has never been rendering speed. X is actually pretty fast. It just suffers from a fair bit of latency due to the architecture of X in general. So does MacOS X, because it has a similar architecture, but it does a great job of covering it up where it has to, and the MacOS X GUI does a few things that normally have to be handled by the tookit on X.
Really, both Qt and GTK are equally bad at covering up latency. Obviously that’s not always possible with X – you might be running over a high latency network. The problem is that most of the toolkits require far too many round trips to the X server to get anything done, so they appear to be a lot slower than they really are. That’s where the complexity of each toolkit comes back and bites you, although they’re far superior to a simple toolkit of application development.
Try an app written in a very simple toolkit, like FOX or FLTK. You’ll notice two things. First, they run about as fast as unthemed Windows apps that don’t use custom widgets (although not even Microsoft’s software uses the built-in widgets anymore). Second, they look primitive compared to a decent GTK or Qt app.
Windows, on the other hand, isn’t really that fast, but makes up for it by having lower latency (the single advantage of putting much of the GUI system in the kernel) and having a much simpler widget set than MacOS X or any modern X11 toolkit. Apps using custom widgets seem to render things slower, but still don’t have the same latency that X apps do.
Back on topic, it’s great that we’ve got a Qt version of Mozilla that looks like it’s actually going to be maintained. Even if nobody actually uses a Qt-compiled version of Mozilla or Firefox, quite a few people would use a Gecko KPart, and a few distros would probably come with it installed by default, so that’s reason enough to believe it’ll be actively maintained. Unlike the port that Trolltech did, which simply sat there until it was incompatible with the latest Mozilla sources, and the latest versions of Qt.
Windows employs a lot tricks to decieve users into thinking apps are fast.
Well, one can argue than perceived speed is what matters, so “deceive” is not the right word. Anything an OS/toolkit/window server/window manager/whatever can do to make you think a _desktop application_ is fast actually makes it fast.
Keeping applications in memory that is not needed for something else is not a dirty trick by MS but good use of the memory available. Actually, Linux and Linux DEs (at least KDE, I don’t really know about Gnome but I would expect they do the same) do the same thing as windows but even more extensively, which is a good thing. (But of course leads to some people complaining that kde is a memory hog because all their ram is used, as if the purpose of the ram was not to be used)
“Try running Gecko on an AMD K6-2 450MHz, it can happen, but it runs oh sooo slooowww.
KHTML on the other hand blazes, and loads (guesstimating here) 96% of sites perfectly.”
You’re absolutely right! Running Gecko based apps (Firefox, Mozilla, etc) on K6-2 CPU based hardware is very slow. The hardware might be old, but still functional.
I have two AMD K6-2 powered boxes that I haven’t gotten rid of yet. One of them runs OpenBSD and the other runs FreeBSD. On the FreeBSD box I run Opera since it runs much faster than anything else I’ve tried. The use the OpenBSD box as the firewall so I rarely fire up the GUI. I wish there was an elinks port for OpenBSD though.
I haven’t tried KHTML (Konqueror) based software in a long while. It takes way too long to compile KDE on either of these boxes that it’s just not worth it. The last time I used KDE on the FreeBSD box, I did notice that Konqueror did quite well. Although, that was years ago.
For now, on FreeBSD I’ll just stick to Opera since it handles old hardware just fine. I must admit though, the 6.x series was faster than the 7.x series on this hardware.
I never called them dirty tricks. And don’t think Linux makes extensive use of preloaded applications. I know for instance that Windows loads Internet Explorer, Microsoft Office, MSN and many other applications like Quicktime, Firefox, and any other program you instruct it to load on startup.
Linux on the other hand loads deamons into memory. I know KDE just recently allows you to preload Konqueror and to some extent Openoffice.org, but I don’t think such practices are as prevalent as you are suggesting.
I agree. I think Apple is having its own codebase and KHTML and Apple versions are different. How come gmail supports safari and not KHTML if both have the same codebase ???
I personally prefer both firefox and Konqueror and I use them randomly. I think Konqueror is less mature than firefox. Nevertheless, I think it will grow as time passes.
On Windows K-Meleon flies on a PII/450-class machine.
Mystilleef:
The speed of GTK on your machine may be good. Still, other people do have speed problems (obviously, judging by the amount of gtk-is-slow complaints) with gtk, myself included. Very noticeable when resizing large (~600×400) windows/widgets.
Interestingly, disabling double buffering in gtk speeds up by a factor >= 2, making it just as fast as gtk1/qt.
So on my box at least, double buffering is the bottleneck. I, for one, won’t notice any speedups in pango rendering :/. Possibly XCopyArea is to blame, in which case it could be, I guess, a driver problem. Running nvidia gf4mx here. What graphics card do you have?
// Johan
I think you shouldn’t be that harsh with people that don’t share your opinion, especially since you have shown that you don’t always know what you’re talking of (Mozilla is ALWAYS compiled against GTK, just not the same version).
Like I said in another thread, GTK2 might be fast but it sure feels slow. Perception is probably the most important thing in a GUI. And since hundreds of people complained about this, many that are not regular here, I don’t think it’s just a rumour.
I have used GNOME 2.4 and 2.6 for about a year. I have also used GTK applications on Windows. They all suffer from resizing, redrawing and responsiveness issues (responsiveness is good on Linux, though). If these issues were limited to Linux, I would say that the X server could be the problem but as the toolkit suffers from the same issues under Windows… And no, I am not using a “slow distro” and my installation is not borked. I am using Gentoo like you do (except on my laptop, where I have to use Fedora). And I have fairly fast computers (AXP 2500, 512MB; AXP 2500, 256MB; Centrino 1.7, 768MB).
Firefox feels faster on Windows because it’s not using GTK. Simple as that. Of course, opening 10 bookmarks at the same time might be faster on Linux but who’s doing that? And we’re arguing on the perceived speed of the toolkit, not the processing speed of the application. GTK is not opening the 10 bookmarks at the same time… Mozilla does. GTK merely display the tabs.
People are not complaining on QT’s speed because it’s always improving. And quite frankly, it was always fast for me… However, I favoured GNOME/GTK until recently because most applications for this combo were better.
But this GTK+ is slow argument just needs to stop. It’s especially annoying when it is being fling about with absolutely zero credible evidence or facts. Every gives their own ‘feelings.’ And quite frankly, no developer gives a damn about feelings.
A perception issue won’t be solved by a profiler. The developers have to give a damn about their feelings. But hey, I guess it’s easier to bury your head in the sand than facing the problem…
Apple Safari and Konqueror (KHTML) do not have the exact same codebase. At a certain point in time, Apple took the sources to KHTML and started modifying them and they have distributed the changed sources on their website from the beginning.
Apple is making rapid chances but because Apple can’t provide the changes to KHTML in digestable chunks the KHTML developers are behind Apple quite a bit. Also, KHTML doesn’t have a big team of paid developers behind it. That doesn’t help aswell.
Just recently KHTML did get support for GMail by the way. More information is to be found in the EXCELLENT KDE CVS digest over at http://www.cvs-digest.org .
We can’t argue on perception because it is silly. You don’t get it. Your feelings don’t count. Because everybody will continue to feel differently.
For instance, you feel Mozilla on Windows is more responsive than Mozilla on Linux. I don’t. You feel GTK+ is less responsive than Qt. I don’t. You feel GTK+ is slow. I don’t. You feel GTK+ apps suffer from resizing issues, I feel the same of Qt apps. And the feelings continue. So whose feeling is right and whose is wrong?
Feelings are exactly what they are, feelings. If you go write a bug report to the maintainers and tell them GTK+ feels slow. You’ll get a thousand replies saying it feels fast right here.
Do you see why perceptions are not a valid criteria for measuring a toolkit’s performance. There are more scientific, more reliable and more credible was to measure a toolkit’s speed and rendering abilities, and feelings don’t count!
Feeling GTK+ is slow is just a blanket statement. Because I can summon ten people who will feel it is fast and will feel Qt is slow. So lets get over our feelings, and provide hard proof for people who will use this information to solve the problem, if indeed there is any. No more feelings, please.
Then fire up synaptic, make the package list larger and try to scroll it up and down. On my Laptop (800Mhz,256K Ram,Debian testing) it IS slow.
But don’t worry, I still continue to stay with GNOME 😉
Woah, got it working (gentoo, amd64, gcc 3.4)
Screenies:
http://img74.exs.cx/img74/4026/mozqt-google.png
http://img82.exs.cx/img82/4056/mozqt-slashdot.png
Few things i noticed:
– The toolbar is completely fscked up (Zack noticed this in his blog too)
– It’s _incredibly_ fast compared to Gecko/GTK2
– Resizing is superfast too
– All widgets (eg textfields, dropdown boxes, scrollbars and buttons) are showed with the native look & feel, which is *not* the case in Gecko/GTK2
– Lots of debug texts in the console
– Some repaints missing, eg need to scroll up/down a bit to show some images
– Dropdown boxes placement is not correct, they appear to much to the left side
Considering this is not even a alpha release, I’m _very_ impressed by Gecko/Qt. Way to go Zack!
Do you see why perceptions are not a valid criteria for measuring a toolkit’s performance. There are more scientific, more reliable and more credible was to measure a toolkit’s speed and rendering abilities, and feelings don’t count!
Feeling GTK+ is slow is just a blanket statement. Because I can summon ten people who will feel it is fast and will feel Qt is slow. So lets get over our feelings, and provide hard proof for people who will use this information to solve the problem, if indeed there is any. No more feelings, please.
*Beep* wrong answer. There’s no need for any kind of proof. If they feel it’s slow, then it’s slow.
That’s why they are called _user_ interfaces. That’s why we speak about _human_ guidelines.
Perception is everything. What’s a real, scientific answer, then? Study users perception. See what make them think something is slow. Change the interface so that they don’t think it’s slow. Rinse and repeat until the amount of users who think it’s slow is near to 0. You know what? That’s probably what MS did in their usability labs when designing their ‘ways to deceive’ users.
Your ‘scientific, more reliable and more credible’ ways are really nothing when it comes to things that interact with humans. That’s why benchmark have no values. That’s why 33 Mhz 486’s sometimes felt quicker than our 3 Ghz machines.
The whole point of my argument is that users’ perceptions vary. Perception is so abstract it is impratical to measure. Programmers are not psychologists that they now begin to study perception.
Even if GTK+ was sped up by ten folda tomorrow. I can bet you there will still be hoards of people lamenting about GTK+’s slowness, again without proof just feelings.
There are many things that are based on perception, but people largely agree on. For example, I open up Nautilus to /usr/bin. I then open up another Nautilus window to /home. I resize one over the other. It takes nearly a second for the underlying window to redraw. Yes, that’s perceived slowness. No, it’s not something that is entirely subjective.
People’s visual systems work very similarly. There are a lot of things people perceive, that are perceived similarly by all people. When you display a large white area, then fill it with icons, then people will perceive slowness, no matter who it is.
There are many things that are based on perception, but people largely agree on. For example, I open up Nautilus to /usr/bin. I then open up another Nautilus window to /home. I resize one over the other. It takes nearly a second for the underlying window to redraw. Yes, that’s perceived slowness. No, it’s not something that is entirely subjective.
I just did the same with Konqueror. And I see visible redraws. This must mean that Qt is slow too.
People’s visual systems work very similarly. There are a lot of things people perceive, that are perceived similarly by all people. When you display a large white area, then fill it with icons, then people will perceive slowness, no matter who it is.
People’s perception of speed isn’t nearly as similar, especially at fractions of a second. We are talking about things refreshing and redrawing at the micro second levels.
Besides, I can sit down I look for visual pitfalls in any toolkit by, but is it really practical.
This is a general complaint about every Linux Distro for the Desktop (Not just Novell) — Why MUST the default icon size be SO BIG? I use a 1600×1200 res. and I set the icon size a bit small for most people. I realize I’m a bit extreme, and I’m not the norm, but I beLIEve there is a happy medium.
someone mentioned that it’s possible to disable double buffering in GTK2? Could anyone tell me how to do that?
Okay, I *don’t* see that in Konqueror. What’s your configuration, anyway?
With regard to perception, people are extremely sensitive to visual artifacts. It’s quite easy to detect flicker in drawing even when it happens in less than 1/10 of a second.
…I’d probably take perceived performance over actual performance in respect to GUI performance.
Yes, flicker is easy to detect. I even postulated earlier on this thread that the goal should be render smoothly and not fast. My girlfriend can detect flicker when the our monitor’s refresh rate is around 65Khz. At those level I still don’t detect flicker. Everyone doesn’t visually perceive rendering errors the same way, or react to it similarly.
For instance, I don’t find the resize issues disturbing. Apparently a few people do. It doesn’t bother me at all. Because almost all toolkits I’ve used suffer from on form of rendering issue or the other. And to me GTK+ is plenty fast. Others say its slow. I even mentioned GTK+ is more responsive to me, than Windows XP.
With regards to Konqueror, I have the default configuration. And I see resize lags when resizing manually and when using the maximize/unmaximize window control widget. I have a 1.4 GHz Athlon box with 256MB RAM.
For me, Firefox under Windows take about 3 seconds to start up, under Linux it takes about 10 seconds. Subsequent start-ups take less, about 4 seconds. I can’t comment on UI responsiveness because I’m using GTK-Qt.
Since you’re using GTK-Qt, I’m assuming you’re also using KDE. It’s important to note that when you start FireFox, it still has to load the GTK libraries, since all you’re using prior to that is most likely Qt. This is probably the source of the slowness in starting FireFox.
In Windows, all the libraries/toolkits/whatever have already been loaded, so the Win32 port of FireFox will load faster than the GTK port in KDE.
“Not true. I run both Linux and Windows on the same box(800Mhz Duron, 256MB ram).
On Windows, Firefox is definitely faster – it renders pages faster and it responds to UI events faster than it does on Linux.”
uh-huh. And what precisely does rendering pages have to do with the GTK+ engine? Given that rendering a page uses the GUI toolkit…hardly at all.
I just opened up those two Nautilus windows and played around for five minutes. Couldn’t get anything to take two seconds to redraw, let alone a minute. Sure, this is a fast box, but that’s a big difference, my friend…
Rendering involves drawing graphics and text. And guess what, it uses the toolkit for that. Yes, It Fucking Does.
ooh, fair point, ya got me there. chalk it up to holiday Monday.
I personally don’t see why people like to defend GTK+ so much. Apparently, many people have issues with it. But yeah, let’s all pretend that there isn’t a problem, and make everyone that claims otherwise feel like a fucking moron!
GTK+ is slower than Qt. That does not mean Qt is lightening fast, because it doesn’t take much to be faster than GTK+ 2.0. Ever since the coming of GTK+ 2 I have noticed how incredibly slow it is compared to GTK+1 and Qt. But guess what. Qt 4.0 will use double buffering all over the damn place. I tried Qt 4.0pr1 and Qt 4.0pr2 (those are pre releases) and it feels slow as shit.
OSX uses doublebuffering all over the damn place too. I doubt it’ll be a suprise that people find OSX’ UI more sluggish than Win32, GTK+1 and Qt <= 3.
See a friggin’ pattern here? It’s the doublebuffering. And it sort of makes sense. We’ve only got measily 3GHz machines these days. They need to render a HELLUVALOT of pixels… TWICE!
So while doublebuffering is really cute and stuff, it comes at a price. Hopefully Qt 4 will allow us to disable the damn doublebuffering, because I was never bothered with the minor flickering that Qt 3 has. I am however bothered with the penalty that comes with doublebuffering. If only someone could tell me how to disable it on GTK+ 2…. *cries*
I never said it took a minute. I said it took nearly a second. A second is a very long time, given that human response time is about 1/4 to 1/3 a second.
Richard, double buffering only happens when you use xcompmgr and xorg 6.8.0.
Anonymous: No, gtk2 double buffers all widgets by default.
Richard: I made a trivial change in gtkmain.c but unfortunately it’s not worth it because of all the flickering it causes (I guess it would be much less if widgets didn’t assume that they were double buffered). The speed boost is huge though.
Also, the qt4-pr seemed to suffer from the double buffering as well. It really doesn’t seem to be the toolkit’s fault, but some driver/architecture problem (it seems weird that today’s hardware shouldn’t be able to handle buffering with ease). Wonder if GL-ification of the X server will help…
From what I’ve read from KDE developers that’s not really true. Apple develops it’s own codebase and does not check in in the KHTML/KJS-CVS (but the source is still open of course). It’s more like a forked project.
It’s quite difficult to take over the changes Apple made.
Not true. Read through the weekly CVS summaries that get posted to dot.kde.org and you’ll notice that a lot of Safari updates/fixes/whatnot have been committed to the KHTML and KJS modules in the KDE CVS. It just takes time to bring in the code from Apple.
I agree. I think Apple is having its own codebase and KHTML and Apple versions are different. How come gmail supports safari and not KHTML if both have the same codebase ???
Duh! Of course they have separate code bases (CVS repos). They are separate projects, managed by separate companies (if you can call the KDE Project a company, that is).
But, they both use the same base, and bug fixes / patches / new features are passed from one project to the other, as the developers have time. Read through the CVS summaries posted to dot.kde.org. You’ll see that the KDE devs just committed a bunch of patches from the Safari people to get gmail working in KHTML.
There aren’t a whole lot of people working on KHTML. They don’t always have the time to read through every public commit message in the Safari CVS repo, and they can’t always port the fixes / patches over to KHTML right away. But code does flow between the two projects.
Konqueror 3.3.1 will work with gmail.
The *rendering* speed of Gecko is *not* lower than khtml. Perhaps the *chrome* of Firefox is less responsive to Konqueror. Compare Safari to Firefox on OS X and you’ll see that Firefox is way faster.