Nokia Closing Australian Office, Looking To Sell Qt Assets 125
An anonymous reader writes "One day after word leaked out that Nokia is shutting down its Qt Australia office, which is responsible for Qt3D, QtDeclarative, QtLocation, QtMultimedia, QtSensors, and QtSystems, reports are beginning to surface that Nokia is trying to sell off all Qt assets."
Seems like selling itself to Nokia wasn't the best option for Trolltech after all.
Re:For better or for worse... (Score:4, Informative)
Re:For better or for worse... (Score:4, Informative)
Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.
And,
Qt itself will not throw exceptions. Instead, error codes are used.
http://qt-project.org/doc/qt-4.8/exceptionsafety.html [qt-project.org]
Which is not to mention the incoherent uses of exceptions and error codes in the C++ standard library.
Re:For better or for worse... (Score:5, Informative)
They could have made widgets hardware accelerated and easily animated.
Yes. And that's how QML came to be, because when you actually try to make "widgets" do all that you end up with something that's not widgets anymore. Do you seriously believe that the mindset was "let's come up with something new from scratch, we've got too little work to do"? The legacy widget model has insurmountable performance issues that cannot be overcome in that model. If you don't understand that, you need to do some research first, perhaps actually try coding something up and convincing everyone how your supercool painter widget based model keeps up with competition.
There's no way to get good performance from a painter-based architecture that asks everyone to repaint their part when something changes. This model made sense for a while because common graphics hardware was generally slow and had no acceleration to speak of when it comes to graph-based representations of the visuals. It doesn't make any sense anymore. When a window moves and is to be recomposited, you shouldn't have to transfer more than a command or two to the graphics card to change a couple coordinates. It'll be picked up next time the rendering is done. In the painter-based model, at best you have backbuffers for every window (even if a window has a flat background that can be represented by two flat shaded triangles -- two dozen numbers at the most, not a megabyte), and those backbuffers have to be composited.
The widget model not only sucks performance-wise, but it also sucks resource wise: you need a lot more memory and a lot more memory bandwidth to render even fairly simple things.
Re:For better or for worse... (Score:5, Informative)
I wish to elaborate on why the painter model is inefficient with today's GPUs.
The painter employs an imperative approach that does not allow for much freedom. Example: begin(), line(), text(), line(), end(). The two line() calls should be grouped together, but they cannot, because then the result would not be equal (what if text() drew over the first line, then the second line() call drew over the text for example?). The result is pretty bad: the underlying implementation has to perform tons of unnecessary shader switches (since font rendering most likely uses different shaders than the line drawing code), and perhaps texture switches (if texture-based AA is used). In addition, every time the painter is used, a vertex buffer has to be filled with vertex data. It cannot be easily cached. And this applies to *every* begin..end painter sequence.
A declarative QML-like approach is a much, much better idea. The fundamental reasons are that (1) the renderer now always has a global picture of what the frame shall look like, (2) intermediate results are much easier to cache, (3) no strict sequence of drawings is given, therefore the renderer is free to reorder and merge drawcalls in any way it wishes. This benefits even pure CPU-based rendering - the Enlightenment Foundation Libraries [enlightenment.org] render using a graph, and are extremely efficient (they clip and cull primitives early on, group primitives together, IIRC can even detect accumulated opacity from several alpha blended layers ..).
C++ QML bindings would likely consist of an API that can modify the graph. Either way, the painter-based approach is gone.
Re:For better or for worse... (Score:4, Informative)
QML is a result of Nokia's (failed) mobile efforts, but thanks to it, Qt (unlike pretty much any other toolkit) is actually able to create competitive interfaces, regardless of whether the competition is using traditional widget-based interfaces or Metro-style interfaces.
It's not the only toolkit - WPF is quite similar, and shares many of the same concepts. Qt is the only such C++ / native code toolkit, though, and it's a fair bit faster than WPF. And portable to boot.