At Akademy 2008 in Belgium, Qt developers Simon Hausmann and Andreas Aardal Hanssen announced dramatic improvements in the web browser engine in Qt and the canvas that is used by, for example, the Plasma desktop shell. Video support, animations and transitions, optimisations to speed up painting and animations, and new graphical effects open up nearly endless new possibilities for developers to present their user interfaces with. Read on for more details.
Reflecting a video in QtWebKit
Hausmann demonstrated a WebKit based Konqueror web browser displaying video content through the HTML 5 video tag. With only one line of HTML code, video content in Ogg format can be embedded in webpages. Style elements can then display reflections of this video widget. Naturally, the underlying multimedia engine used in QtWebKit for showing video content is KDE's Phonon multimedia layer. Animations will also be possible. By adding simple CSS properties to your webpage elements, you can animate, rotate and fade those elements. Writing rich and animated webpages and of course embedded web content in applications becomes a breeze with QtWebkit.
After Simon's demo of QtWebkit, Andreas Aardal Hanssen entered the stage to show some of the improvements that will be in Qt 4.5 which will be released later this year or in early 2009. After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma, more breakthroughs in the development of Qt's graphics canvas are coming up. Speed-ups of up to 40 times faster in some cases go along with a set of really nice additions that are unparalleled in today's toolkits and can only be dreamt of in competing offerings. Improvements that will be available in Qt 4.5 include:
- Transition animations in user interfaces
- Optimisations in painting operations
- They are also looking into extensive support for animations through a new animation API, due for an unspecified future Qt version. Graphical effects like blur, bloom, shadow and opacity for items on the GraphicsView are being looked into as well.
Hausmann's and Hanssen's future plans for those components in Qt have been met enthusiastically by the KDE developers. Soon, these new features and optimisations will be available to KDE users around the Free world.
Comments
are there any benchmarks? does it partialy solve the nvidia problem? etc
That was my first thought as well. The nVidia part, that is. I hope so. I personally have only used KDE4* on Live CDs since KDE4* isn't ready for "me", yet (yes, I like *real* icons on the desktop, and a hideable "kicker"). I was going to jump to 4.1 because, well, I really want to, but the nVidia problems have kept me at bay hoping that by 4.2, nVidia will have gotten their act back together enough.
If these performance boots help make KDE4* on nVidia cards much less painless, then I can work around some of the other limitations of KDE4 until they are implemented.
Why should the KDE or Qt guys fix nvidia bugs ?
nVidia recognizes that it's their fault and will release a drivers fixing these bugs, but it's not a KDE or a Qt problem when the vesa driver is faster than the nvidia proprietary driver.
well, my question was actualy if the speedup makes up somewhat for the nvidia slowdown. but i forgott that the new driver will probably be out before i got a kde 4 with qt 4.5
I wasn't suggesting that TrollTech or KDE Devs somehow become nVidia gurus and fix their busted module. I was more asking if these tweaks that have been made make life easier for us nVidia users.
I'm not nieve enough to thing that TT/KDE is somehow responsible for nVidia screw ups.
We hope confidently that the nvidia issues are solved *before* 4.5 ships. Qt 4.5 might make some things on nvidia faster, but it's really general optimizations, not nvidia-specific ones. All users should benefit from those optmizations, since they for example improve clipping on graphicsview.
Nvidia's problem are more OpenGl oriented so the Nvidia problem can only be fixed by Nvidia. QGV doesn't use Graphics Acceleration.
nvidias opengl driver is fine. their 2d acceleration isn't working with qt4. and graphicsview can actually use opengl for rendering.
NVidia's 3D drivers are among the best.
NVidia's 2D drivers suck. All 2D is a bit slow, but it is usually not very noticeable. Qt4 amplifies the inefficiency by making heavy use of 2D acceleration.
Should have been here about 10 years ago. I know some SMIL 2.0(HTML+Time 2) and these years waiting for these type of things to go mainstream have made me indifferent. By the way, how old is Adobe's SVG viewer that has 1.0 capabilities? And SVG 1.0 is still not fully available on the 'cool' browser today. The third world war will probably arrive by the time developers get their acts...oh never mind...what's the point.
Adobe gave up on their SVG plugin since they bought Macromedia Flash. What else could we expect from them...
http://www.adobe.com/svg/eol.html
Hopefully Firefox is going to make their svg viewer usable on IE (same with canvas and JS2.0).
>>Hopefully Firefox is going to make their svg viewer usable on IE (same with canvas and JS2.0).
Huh? Can you please elaborate? Is there any truth on that or is just a wish?
Uh... What? That statement made no sense. On so many levels.
1) It's not like it's a plugin or something. It's integrated into gecko's rendering engine
2) Why would gecko devs care anything about IE?
3) IE sh!ts it's pants whenever it is handed XML anyway. (SVG is just an XML namespace)
I can tell you mean well, but your statement comes off as being very trollish.
Trying to explain in a simple way: IE sucks and it's in M$'s best interests NOT to add cool non-proprietary stuff to IE. There isn't as much motivation to work on SVG and friends because mainstream web can't use it. If IE wasn't the mainstream browser web page authors would be free to use those features, and developers would have more reason to work on them.
Ah, how is it a 'troll' when the reality is that the SVG implementation in Firefox is not 100% complete; may I suggest you look at the latest info on it, and you'll find that large chunks of the SVG specification haven't been implemented yet.
All very nice to rave about how great a feature is, but pointless if it isn't implemented properly.
there's a typo where a sentence is split in two :
"After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma. More breakthroughs in the development of Qt's graphics canvas are coming up."
should be a single sentence, .->, and M->m
You are wrong.
I think he's right.
He's right, but the resulting sentence after the change isn't exactly pretty either... really not pretty.
"After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma. More breakthroughs in the development of Qt's graphics canvas are coming up."
This is fine, but to be succinct and proper with English Grammar:
``After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma--more breakthroughs in the development of Qt's graphics canvas are coming up.''
In LaTeX terminology there should be a \textemdash for the ``dash'' whose purpose is to emphasize interruptions in sentences by:
1. to emphasize explanations, including appositives, examples, and definitions;
2. to emphasize a contrast;
3. to emphasize an ``aside''; or
4. to show hesitating or broken-off speech
Too bad KDE 4.2 will not be based on Qt 4.5, that means we'll have to wait for KDE 4.3 to have a good web experience using Qt/KDE technologies (KHTML is not good enough unfortunately).
Aren't there QT 4.5 preview packages available right now? And don't they include a basic QT/Webkit browser?
We're on a 6 month release cycle though, KDE 4.3 will be released pretty soon after Qt 4.5.
You mean July 2009.
As far as I know, no decision wether to depend on Qt 4.5 has been taken, so you're "Too bad ..." is a bit premature.
> you're "Too bad ..."
it's "your "Too bad...""
and kde4.2 will be based on Qt4.5, it's been said on the ML.
Ha yea, I was confused. Right, I don't see why KDE 4.3 wouldn't be based on Qt 4.5...
Will the performance-enhancing improvements introduce incompatible API changes? Will it be possible to get some of the performance improvements by building KDE against Qt 4.5, even if it doesn't actually require it?
From reading the blog where the Troll mentioned the 40x improvement it *sounds* like it doesn't require changes to the applications, so I think (at least that change) could be gotten for free just by upgrading your copy of Qt.
Even if it requires a change it probably won't be too big, and if it would have a large impact the distros could ship a patched version of KDE with a 4.5 dependency.
(mind you, I'm just guessing based on the wording in the blog)
As far as I know Qt has strict API and ABI policies for forward compatibility so any application written with Qt 4.x should be compatible with Qt 4.y where y > x for the whole life cycle of the Qt 4 series.
Not doing so would mean shooting themselves very hard in their commercial foot...
something they probably won't enjoy.
KDE4.0 could easily be built against 4.1, and get many of the improvements (performance stuff, bugfixes, etc). KDE4.1, if built against Qt4.5, would get the performance and WebKit improvements without any source modifications. Even if KDE4.2 isn't dependent on Qt4.5, you can always compile against it and get the improvements.
You don't need to recompile. Just install the new Qt libs.
I can't believe my eyes!!! A new animation API too !! That was what I was waiting for :D Please please, post the talks online, some timings, git references or whatever.
I need more!! ;-)
Great work peeps!
Now I'm sure most of you have heard that a port of Mozilla 1.9 (and Firefox 3) to Qt 4 is underway. On one of the developers' blogs (http://blog.vlad1.com/2008/05/06/well-isnt-that-qt/), he notes that while Qt is a well-designed modern toolkit, it has a few quirks:
*He notes that a drawGlyphs method on QPainter something that would take a QFont and an array of glyphs and positions - is missing;
*QPainter cant do arbitrary path clipping with antialiasing
*Cairo has a few optimizations (e.g. with paths) that QPainter doesn't.
Will these quirks be addressed in upcoming Qt releases? It would be awesome to have a better-integrated Firefox (Konqueror is great too, but just doesn't offer the same array of extensions). Thanks!
Actually, having Firefox do its rendering via Qt has little to do with integration. Integration of the webbrowser is about a bookmark system, shared proxy settings, mimetype settings, certificate integration with KIO, password integration with kwallet and of course things like file dialogs from KDE. Using Qt as rendering engine is just one step.
File dialogs is the killer thing for me. I can't stand the damned GTK file dialogs. And yet I really love Firefox. And I think on openSUSE which I've been using lately, I set proxy settings in KDE, and Firefox recognizes them. There is an option in Firefox (it may be an openSUSE patch) to recognize system proxy settings.
Web browsers often have separate mime settings from the rest of the system, because you either open it as a plugin, save the file, or pass it to an app. It is more than just saying app x is related to that file.
kioslave and kwallet integration would be nice, but frankly Firefox stores passwords well enough on its own, where as I find the kwallet pop-ups to be a little annoying.
There is a hack around that makes a lot of GTK applications use the Qt dialogs instead. Works pretty well, and makes GTK apps play a bit nicer in your Qt environment. Of course, don't expect KIO tricks to works all of a sudden.
How nice of you not to mention what it's called. Just that it exists... buhuuu!
http://kde-look.org/content/show.php/KGtk+(Use+KDE+Dialogs+in+Gtk+Apps)?content=36077
Sorry, yes. I did not have time at that point to look it up. See it as an exercise to hone your Google skills ;-)
I can't imagine a Qt firefox using a Gtk file dialog, could you ;). Actually, I'd expect it to use the standard QFileDialog. While it's not as awful as the GTK one, it isn't KDE either. Of course you can always use KGtk or KQt, respectively.
I've used the latest build and at this moment it does use the Qt file dialog as expected.
It's total pre-alpha material and practically unusable for normal browsing, but it's still sorta cool....
(It also has a lot of potential!)
Always good to hear. I may be hopelessly addicted to KDE's application-specific file dialog bookmarks and I may be doing fairly well with KGTK, but it'll definitely be a step in the right direction to have native support for Qt file dialogs.
I could wait a few more days for the videos to be published (but whats the fun in that? :P), but did the talk cover anything about how the QtWebKit API is going to be extended? The main-snapshot documentation (on doc.trolltech.com) has already been extended to include QNetworkDiskCache but I haven't noticed anything about exposing the DOM (directly via the C++ API) or anything about NS plugin support in a while (I had heard that it was in the svn server upstream a while ago)?
I'm also hoping there'll be more information about the new KJS implementation (Frostbyte, I think it was called?) and some of the other stuff going on in KHTML that I've seen blogs somewhat mentioning in the past.
So far I've really enjoyed developing against QtWebKit (the trolls have done an outstanding job with the API so far!) and loved being a Konqueror+KHTML user for quite a while, both are very nice rendering engines and I hope we get to have both actively developed for a long time to come!
Frostbyte went into SVN before KDE 4.1, http://www.kdedevelopers.org/node/3476
For netscape plugin support I can tell you that QtWebKit in trunk already has this support. And as for public API to control these plugins see this:
http://code.staikos.net/cgi-bin/gitweb.cgi?p=webkit;a=shortlog;h=adam/ne...
Also, squirrelfish is the name of the new JavaScript engine in WebKit. And yes, this will be included in the next version.
I'm not sure that a public DOM API will be ready for the next version. It is a big undertaking and could dramatically increase the size of the public API. What's more, it is important to get it right.
You won't see much information on KJS from aKademy since neither Harri nor myself are there; nor is the KHTML uber-guru Germain. ...And besides, being old-school KDE guys we're not big on PR and flashy demos anyway. The initial frostbyte version (-41.0) is indeed in 4.1.0, and I've tweaked a few things since then, though nothing major. I tend to work in a funny way where I spend a lot of time thinking over a design problem at odd times, then when I am I finally happy I go ahead and try stuff... Except even on small stuff I tend to sit on patches for a while since something is always bothering me.
(e.g. stuff like better for ... in behavior on dense arrays and better handling of large
object literals inspired by one of the posts by vandenoever).
Wrt to KHTML stuff: the biggest thing in 4.1 would be contentEditable, though the command set is currently somewhat limited. For 4.2, an ultra-smart SoC student is working on picking up the SVG code from WebCore, and is trying to do so largely through a compatibility layer to keep things from diverging. Though, it is hard since we have a far more minimalistic design philosophy. Can't really give any big KHTML plans from myself, since I tend to just pick off areas which I think need work... Right now e.g. load events from iframes/objects are a bit wonky, though their behavior overall is a lot better after
the big rework in 4.0...
being old-school KDE guys we're not big on PR and flashy demos anyway
That tastes a bit odd: showing of a new feature once in a while or posting short blogs about current development has nothing to do with PR or "flashy" demos. It is another way of communcation with the users.
There are several ways to communicate with users: e-mail, blogs, news, irc, bugzilla, surveys, and so on. Every project picks the set they think fits their style best.
You didn't pick "web presence", ok - but putting it like "I'm too cool for company like PR" is just plain wrong, both things have nothing in common.
"That tastes a bit odd"
Speaking of odd, he never said what you imply in your post, he just said he doesn't (often/ever) show up at those big akademy get togethers that KDE has, which is not the same as saying he doesn't talk to "users" at all (heck, he posted here didn't he?). Jeez, lighten up.