Thursday, September 06, 2007


Does working on the 3D stack make me look fat? Give it to me straight. I promised myself I won't cry no matter what the answer is. As I mentioned in my last blog I'll be getting awfully kinky with our 3D stack and people wondered whether my work on it affects Quasar. Well, just as me moving didn't affect my habits with regards to taking showers (which I do frequently, i.e. every christmas or so), smoking (never ever), being awake (at least once per day) it also didn't affect my spare time habits (except the "starving" thing which was one of my favorite past-times in Norway). Since Quasar was always my spare time project, my move affected it as much as me buying new sneakers affects temperature in Japan (which it doesn't, assuming of course that the folks in Japan won't find the vision of me in the new sneakers so insanely hot to increase the temperature of the whole country).

Aaaanyway, so what is Quasar? Besides being a word that starts with a Q, has some other letters in the middle and sounds funky. It's a dynamic rendering framework, which in turn begs the question "what the hell is that?" ("the hell" being an optional part of this sentence).

Let me lead you through the evolution of Quasar and hopefully at end of this trip we'll be on the same page with regards to what we really need in terms of a graphical framework on the desktop.

Quasar started as a pretty basic image manipulation framework. I wanted to make sure that people can chain filters e.g. read-image->scale image->blur image->render image. It was a linear pipeline. The thing that made it important to me was that it was focused on hardware acceleration. This is a very important point which I want to underline.

I'm not interested in software based effects. This is not to say that the software versions of all of them shouldn't work, I just refuse to bother. It's 2007, even phones come out with some kind of gpu in them, worrying about software based graphical effects does to your time what listening to financial advises from blogs of Open Source engineers does to your money - wastes it (which reminds me, I also have some financial tips for you. Well, tip, just one. It's not the quantity but quality as they say. Invest money in winning lottery tickets. Note that I said "winning", buying any other kind would be silly. You're welcome). With the work we're doing right now at Tungsten Graphics our graphics stack will be extremely good at it.

When I was a kid we didn't have fancy graphics. We had crackheads, alcoholics, pimps, thugs and plenty of other shady characters none of which, I'm fairly certain, did computer graphics (childhood memories warm your heart, don't they?). If my years of working on a vector graphics framework taught me anything (besides how to write a vector graphics framework) it's that the most fundamental part of a high level graphics framework isn't the framework at all. It's the way in which you let people design their applications, their interfaces. What use are blurred perspective transformations if two people know how to use them? What's the point of 20 composition modes if people can't be bothered to understand the basic 2.

So I started seeing effects as a step, a very crucial one, on the way to very appealing interfaces, but not my ultimate goal. In a desktop world we're dealing with graphics on a fairly abstract level, because we're doing graphics for non-graphics people. Good effects framework is not one that has every possible effect ever invented but one that makes it possible to quickly add those effects to ones application/interface and end up with something usable and pretty.

Finally inherent complexity of graphics bothered me. Maybe not even the complexity itself (especially since it's where my job security stems from), but the fact that it takes a lot of knowledge to understand and know the fast paths. The knowledge necessary to extract that logic can be easily abstracted in a graph like structure. That's what I started doing in Quasar.

Quasar is a dynamic graph. One that can rearrange itself to produce the output in the fastest possible way.
Those are the three basic tenants of Quasar, to rehash, they are:
- hardware accelerated,
- easy to incorporate and produce good looking results,
- smart enough to produce the results in the quickest possible way, no matter how little knowledge its users posses.

The way it works is that one creates the rendering in a graphical builder (which at the moment looks very much like Quartz Composer), loads it up in application and, well, that's it.

Of course, the graph can be created or modified at run-time just well. It follows the "tell me what you'd like and I'll give you that in the best way possible" principle.
Having said that Quasar is still far from complete but I just posted where to get it from on the relevant KDE list (if you don't know which one, trust me you want to wait a little bit longer before trying it out). Oh, and of course Quasar will support full effects pipelines on top of movies (integrated with Phonon).


Anonymous said...

Interesting stuff zack, as always. That last part of your blog reminded me of something I've wanted to ask you ever since I saw some of the videos from aKademy this year; you where talking about integrating phonon with plasma I believe? I.e having phonon output video via QGraphicsView -- what has come of this?

Anonymous said...

don't be too dismissive of software rendering: with the current trend of multi-core CPUs, the need to have a dedicated GPUs might vanish. The AMD/ATI merger is another sign that the CPU of the future might do graphics without the need for a separate GPU. Another thing: Intel is often touting real-time ray-tracing as an important application for the massively multi-core CPUs that they are anticipating to have in the future.

Zack said...

@anonymous1: it's waiting to be integrated in Qt. The Phonon side is basically done in Phonon::VideoFrame.

@anynymous2: no it won't. It might live on the same die which doesn't change anything. Furthermore high level frameworks don't access hardware they go through lower level apis, in this case OpenGL. Whatever future brings the one thing that you can be assured of is that while OpenGL might, and in 99% cases on current desktops will be accelerated, software paths in 100% will not. Hence I have no interest in real time rendering done in software. Now if you'll want to be hand assembly optimizing software effects, great, more power to you.

illissius said...

tenant: someone who rents an apartment
tenet: the word you might've been looking for

just saying :)

klichota said...

The idea (and the graph screenshot) reminds me of Arts (and its artsbuilder). The idea was good, but it never worked.

I hope you will do better than Arts with sound. Good luck :)

shamaz said...

It's good to know that Quasar is not dead. Thank you :)

phonon + quasar + plasma... mmm new possibilities...

Anonymous said...

I am reminded of Clam's Network Manager which let's you chain stuff and effects for sound processing together, and it works :) (It might even be possible to grab a thing or two from there for Quasar.)

But it's also doing a bit better, e.g. participated in Google's SOC

Amin Negm-Awad said...

"(which at the moment looks very much like Quartz Composer)"
What are the differences?

Anonymous said...

Off Topic:

Does graphicview do those nice drop shadows (in your screenshot) with one call? Or do you create a round rect, offset it, then change the opacity (alpha?)



Vokimon said...

Glad to see some reference to CLAM in your blog comments. Some CLAM developers follow your blog ;-) any reuse or collaboration is welcome.

Our NetworkEditor is still pre QGV code, so it gets slow with many boxes.

BTW, you may find useful the data-flow design patterns we identified while developing CLAM. Take a look at the "Typed connections" one, for example.

Anonymous said...

The node editor is a major tool for many graphic software. A parameterizable widget would be very useful to many developers. Is the project available for download or check out somewhere ?

McLoud said...


Anonymous said...

i tried the graph example
clicking select image does nothing :( same for the view button

in the end, i can connect nodes the way the screenshot describes but i get no rendering :(

also, building the tests fails because of the load directive in the pro file

Anonymous said...

btw, any short term updated planed ?