I decided to move my blog and it's now at http://zrusin.blogspot.com/

V for Vendetta is so good. Aaron and I went to see it yesterday. On the way there we went to a really great (and cheap) vegan Chinese place and stopped by an arcade (remember those?). Coming back we got asked for money under a bridge. The irony of having people ask for money from two trolls under a bridge runs deep.

We keep working on infrastructure for Plasma and it's really neat to see it progressing every day. At the moment a lot of people is missing QCanvas from Qt 4. Fortunately Qt 4.2 will have a fantastic replacement in the form of a QGraphicsView. Andreas did an amazing job with getting it in its current shape. QGraphicsView is actually a lot, lot better at being a canvas than QCanvas ever could. Today I added support for playing movies in the graphics view. Movies are just items on a canvas so you can compose on top of them, transform them and so on... A screenshot from a sample application is here: . You can see two semi transparent, sheared movies playing on a QGraphicsView.

Now a little about how SVG, QGraphicsView and Plasma will be tied together. I'm working on incorporating SVG model into a QGraphicsView scene. That means that SVG will be parsed directly into a canvas scene. In turn this means that, since all canvas elements are selectable/movable/transformable, we get a SVG editor. I'm hoping to add scripting, video and audio support to the next version of QtSvg. Just like with QtDesigner people who really don't know how to code can create GUI's for their apps for Plasma we'll have the ability to create organic interfaces in the same way. We'll use SVG to actually store the data and just like with ui files, you'll be able to compile them to native code. Compiling we'll mean creating a C++/JS/Ruby/whatever code which creates the QGraphicsView scene for you and hooks it all up.

Hopefully all this will fully replace all the custom HTML based widgets that we currently hack together. We'll have an all gui editor for those which should immensely speed up the process. So basically we're looking at a Flash like app, in the sense that you'll be able to do rapid development of custom vector graphics based interfaces with full multimedia support. Now that is cool.

Oh, sure, normally when you go to visit your friends they take you down to see the city they live in, hang out with their friends and so on. It's no different when I come to see aseigo, but we do all that while protesting. We went on a protest against the seal hunt today. P-man came with us carrying a plush seal toy. I think that image will define "cute" for me from now on (and being a member of the "cute 4" I know cute when I see it). In general it went very well which is just great.
This trip has so far been pretty amazing. I found out that I'm coming to Calgary last Friday and had 2 days to prepare. Then I found out that I'm speaking at the local LUG about computer graphics, which by the way was great. I got free Snapples and Kinder Buenos out of it which is really all I want from life. Working laptop, Snapple ice-tea, some candy, skateboard, protest for a good cause from time to time and I'm one content dude. Missing out on the first of those right about now but a man can't have everything.

During the last weekend I wrote a new application, an OpenGL extension browser. It allows you to quickly browse through all the latest OpenGL specs and lists the ones supported on your system. It looks more less like this (except of course that your laptop is most likely not broken so you won't get all the neat garbage that you get to see on that image). The app itself is here. In coding related news we're working on Plasma and finally got some ideas down that look pretty solid. Now it's only a matter of implementing them =)

I'm finishing my leave of absence and going back to work. Yes, doing what I wanted was great, but the pay was miserable. So I'll be going back to Trolltech. It looks like Trolltech will pay me to go to Calgary and work on Plasma with Aaron for a bit, which is just great. Plus apparently the love of my life is in Calgary. I know what you're thinking "Zack, but they have Snapple ice-tea everywhere", yes, but not Kinder Bueno's. You don't know love unless you've tried Snapple's lemon ice-tea with a kinder bueno. Let me just point out that our relationship is purely platonic.

My laptop is broken and given that I don't have absolutely any money left to get a new one my hacking time is severely limited. Fortunately for me, thanks to Benjamin Herrenschmidt and the people at Terra Soft Solutions I have a Quad-G5 which is nice. I, of course, work only on GNU/Linux so it took me a little bit of time to get the setup right, especially considering that kernel did not support quads when I got it. Again, fortunately Ben was able to hook me up with a code he and Paulus have been working on and from then on it was trivial. I'm about to sit down to check out how the sound driver is coming along because I don't work without music. One major problem is that I only have NVIDIA's pci-e cards here. Now that's a problem because NVIDIA doesn't release PPC Linux drivers. For various reasons I'd prefer not to hack on it, but I don't have money for any other card. Plus NVIDIA hardware works a little differently than what we're used to. NVIDIA has multiple harware contexts, which is nothing really new because they had it for a long time. In our infrastructure we operate with one FIFO through which command buffers are fed to the card. Technically not a huge issue, just makes it a little less than optimal for working with their hardware.

Short of political reasons, the main one I don't feel like working on acceleration support in the Open Source NVIDIA driver is that I don't have any x86 box at home. Now for those of you who never reversed engineered hardware, here's "reverse engineering 101" (meaning "writing drivers without specifications for dummies", also known as "what drives x hackers crazy" - yes! at some point many of them was sane... the pretty ones mostly... i know, i know they're all pretty):

1. Get hardware, preferably one that doesn't work (preferably not because it's broken but because the vendor doesn't offer support for our favorite operating system)
2. Make sure there's no specifications available (otherwise it's just masochistic and I, personally, refuse to promote that kind of spare time entertainment in my blog)
3. Find system Z where that hardware works, meaning vendor provides driver for that system (we call it "Z" because in my extensive experience things named with Z always work beautifully)
4. Develop a small utility for system Z that dumps state info of mapped memory regions (preferably ones that are relevant to the hardware in use, but I'm far from trying to limit your artistic skills here) and deduct register contents.
5. Write small applications that do very specific things, in this case, for example, display uniform color triangle or a quad.
6. Run your application and compare the regions from before and after the rendering happened.
7. The registers that differ are somehow related to the functionality that your application was exposing. (that's also why the application needs to focus on some very specific feature, otherwise the only thing you're figuring out is how limited your intelect is)
8. Deduce what the registers that changed are for, what values they expect when and where do they want it.
9. Try to produce some code.
10. This is important step - watch your machine crash, reboot and repeat.

Now as you can tell finding a system where one can trace the steps of a working driver is the crucial part of "reverse engineering" here. I can't reproduce it because I'm not a proud owner of such a system. So basically we're looking at hours of more or less educated guessing, which accounts for "writing drivers for hardware without specification - the painful way" (oh, yeah, because the previous way is "easy" and "fun"). Time during which you're bound to crash your machine every single time you try anything. This is what I was doing when I was working on Exa on my Powerbook (with ATI's RV250). After that I decided to cut my hair and go on a leave of absence. Coincidence?

Graphics hardware is very sensitive to any kind of invalid input. Well, most hardware is. A crucial step here that I forgot to mention is that between looking at the memory dumps you'll have to form a more high-level view of how the hardware works. Pretty much the only way of doing it is knowing how a lot of other hardware works, what other vendors are doing, what works and what doesn't - experience. Even after that knowing exactly what was sent to the card that made it crash doesn't mean you can figure out what to send to make it work. I'm assuming here that you're like me and simply never, ever make any mistakes in your code and all problems are simply caused by your lack of knowledge about particular piece of hardware. If you're one of those people who does happen to make mistakes then you're looking at an even more challenging task. That, plus often locking the bus and all kinds of sideeffects in between make this process not a whole lot of fun.

I'm in Santa Clara for the XDevConf. Flying from cold and rainy Philly to sunny Santa Clara is quite a change. I wish I brought my skateboard.

I couldn't get WIFI working in the hotel which was a little disappointing and I forgot to bring an ethernet cable. I went down to the reception and noticed that they charge $5 for renting a cable. I decided that I need to get something good to drink to forget that I'm about to pay $5 for renting something that I could buy for about $1. There's a neat juice store across the street so I went there. I started a conversation about the naming scheme they had for the juices (which was just sad) with the girl working behind the counter and I got my juice for free ("berry blitz with immunity boost" was the name). Equipped with that I went back to the hotel where I started talking to the girl behind the counter and got the ethernet cable for free. Can't complain. Next time I'll be aiming for not having to pay for the hotel

Around 5pm Dave arrived in the hotel and we went out. This was the first time we've met. He's an awesome guy so that was a lot of fun. Around 8 Adam arrived with David Reveman, Kristian Høgsberg and Søren Sandmann and we went to an indian place to grab something to eat (well, "Dave and I" [insiders joke for a friend of mine] already ate so we were just serving as mental support - we all know how shy RedHat/Novell guys can get). On a sidenote given how few X/graphics hackers Open Source has, we really shouldn't be hanging out together

What really makes events like this great is seeing all those people face to face and getting to hang out together for a bit. Presentations are just a side-effect. On those smaller conferences everyone knows what everyone else is doing. So presenting doesn't make all that much sense - having discussions about problems and solving them together is what really matters. Officially the conference is starting tomorrow and I'm sure it's going to be a lot of fun.

Lets talk SWF. A lot of people seem to be mentioning Gnash today. Some seem to think it's a giant step for FSF. I think it's really funny. It's really funny (or sad - it depends how you look at it) how a giant win for FSF is taking a wonderful Public Domain project and basically just releasing it under GNU GPL.

So Christian, GNU Flash and Gnash at least were technically two different projects. GNU Flash is (was?) technically GPLFLash2 which is LGPL licensed (how confusing can you get, eh?), while Gnash is using a relicensed Public Domain SWF decoding library making the whole thing GPL. gameswf has been put in the Public Domain so assigning copyrights to FSF and relicensing everything without making any substantial changes is completely legal. In my opinion morally it's not the most wonderful thing one could do though.

Ariya mentions that we could be Arthuring Gnash. Unfortunately, no we really couldn't. Most of the greatness of gameswf, which Gnash is using, is that it implements its own rendering model on top of OpenGL. That rendering model is rather tightly coupled with gameswf (as it's the core of it) so abstracting it would involve refactoring most of the code.

As to whether having SWF support in KDE would be beneficial let me just mention that of course we have it. I did it about two months ago and I have been contemplating putting it along QtSvg but decided that it's pointless (a little bit about reasons later). SWF is very different from SVG though. Yes, they both are technically vector graphics formats, but their usage is completely different. SWF is used to create complete applications. How many applications written in SVG is there?
There's hundreds of different custom installers for SWF files which turn them into .exe files and allow companies to easily deploy those files as standalone apps.

Not having an open library fully implementing SWF is not a problem. FSF created a flawed problem definition. Gnash, in my opinion, is a flawed solution to a self-created problem.

Format is not a problem. People don't care about formats at all. How many people use hex editors to create SWF files? Right, zero. The reason people use SWF is because the creator for them is simply really good. It's very simple and allows them to create compelling GUI's in no time with very little, if at all, programming knowledge. The fact that we don't have an answer to that is the problem. The fact that we don't have anything that could compete with it is exactly the problem. Use of SWF across the web is just a symptom.

And by no means am I implying that creating a SWF editor (e.g. Flash4Linux) would be a solution. It would be a very neat project (like Flash4Linux is) but it is not a solution. The reason is following: when you're competing with a product you have to give people a compelling arguments to switch. Therefore having exactly the same functionality as the application you are competing against is not enough. Why would people switch if they already have everything you provide? Why would they switch if you're implementing just a little more? If you're trying to compete with a product by trying to copy its functionality - you already lost. Furthermore by consistently following vision of another project, you lose your own and you willingly part with the only thing that could make you competitive which is originality.

The way to compete is by going back and asking yourself what was the scope of the problem the original project was trying to solve? What did they manage to solve? What are the main complains of people who are using it? What are people using it for? What are the main features people love about it? If you have those you are well on your way. Next year it's not Macromedia Flash and SWF anymore but Microsoft Expression and XAML, the year after it could be something else. We need to provide a product that stands on its own merits and presents a better solution to the problem of quick and easy creation of easily deployable applications (well, that and stupid little animations ). Qt Designer or Glade are not enough because they allow very limited artistic freedom and in comparison to what you can do in Flash or Expression apps created in Designer/Glade just look ugly.

I guess now it's obvious why Trolltech will be working on scene graph for the graphical basis of the toolkit.

My last blog entry has been caught by a few sites which described me as a "lead KDE developer". I felt the need to clarify this because I don't think it's fair to all other KDE developers.

I'm not a lead KDE developer. KDE doesn't have a lead developer. We're all equals. In fact that's one of the most beautiful things about KDE!

We (KDE) are making it so easy to join the project and everything is structured around the concept of equality. Maintainers have of course final saying in the development of individual parts but KDE itself is a collective of developers from around the world. All of whom have equal saying. The KDE "lead developer" is the community if you will.

And yes, very soon we will be introducing a Technical Working Group . It was just voted in by the e.V. Now we're going to have another vote to select 7 members of this group. To quote from our definition: " The purpose of the Technical Working Group (TWG) is to define and execute the official software releases of KDE. It should also support and guide the processes of taking technical decisions within the KDE project. It has to make sure that the open source development process is kept intact and the KDE community is involved in all important decisions."

I must say that I'm extremely happy to finally have the foundation for this group. The highly distributed nature of KDE is both a blessing and curse. It's a dreamland for developers already in, but makes it a little hard to find yourself when joining and makes it even harder for outsiders to get answers to even simple question of a technical nature (as many developers usually bring forward many different opinions and answers). Now if people will want to ask those question, they'll be able to get a definite answer from the KDE TWG.

If you think about it, it's really beautiful how code affects the evolution of the social structure around it and how the social structure around code affects its development.

I finally got most the implementation of the HTML Canvas element for KHTML finished. It's in the kdelibs-js branch in SVN. After George/Maks merge their other changes we'll merge it to HEAD. I'm planning to add full OSX Dashboard compatibility layer for Plasma (hence why I've spent most of the day yesterday on implementing the Canvas element).

CoreGraphics supports one thing that I need to add to Qt Arthur and that is a nice support for shadows. It's one of the extensions of the Canvas element from Safari that we won't support for now. I know how I want to do it in Qt, now it's just a matter of sitting down and doing it. This plus seperate transformations on fills and strokes which I had planned on doing anyway.

As for Plasma, I've been toying around with desktop mostly this week. Besides the Dashboard support I'm adding a fairly neat feature to the desktop. Our desktop is going to be composed of layers - each one capable of being created by plugins. The base layer is the background layer. Background layer plugins will be responsible for rendering the, surprise, surprise: background. Since they're dynamic we're going to finally have support for all those neat background effects. For example you'll be able to say, I want a layer rendering plain background, then on top of it I want a water effect and on top of it I want my icons and desktop widgets. Or you'll be able to say "I want background layer that renders backgroun as a perspective which changes with my mouse movements and on top of it icons and desktop widgets". You want E17 animated background? No problem, just load the edj background file, correct plugin will be loaded and will handle it. You want... plain background? Load it. And so on, limited only by the amount of permutations of the desktop layers people will implement. No hacks - everything supported natively.

On the xorg front Eric got Xgl working with xorg cvs, which is extremely cool. I added an older version of glxcompmgr to xorgs/app cvs. Dave has been doing some amazing EGL work. Try it all out, update xorg cvs, compile Xgl, checkout glxcompmgr and give it a testspin. I'm hoping to do most of the Plasma desktop code this week and do some Xgl magic soon after so keep watching cvs.

Spending the last weeks in Calgary with Aaron has been just awesome. Hook me up with a better laptop and a place right next to Aaron and KDE 4 will be out in about 3 weeks Calgary is a very interesting city. Lots of skateboarders and graphics developers, but hey, given that I don't live here I think it's obvious they're missing the best of both worlds. I've actually done a lot more work during the last two weeks but I'll blog about that later because I don't want it burried deep down within one huge blog

I haven't blogged for a while again. To some extend because the things I'm doing at the moment have little to do with KDE. First of all, yes, it's true that I don't work for Trolltech and that I'm back in States. For now I took a leave of absence to work on some other things. Right now those other things are physics; superstring theory to be exact. I'd like to finish my research, write a paper and then we'll see what I'll be doing.

Before turning to physics I've been playing around with full curve decomposition on GPU. There's a number of things that irritate me about the current way our 2D api's are done. One of them is the client side path decomposition. It's really visible since our rendering API's are vector based and therefore paths are a first class citizen. This is of course partially because our algorithms for tessellating complex polygons while considering winding rules are quite frankly embarrassing. Tessellation is a fairly uninteresting problem in itself, that's also one of the main reasons there isn't too many people willing to spend heaps of time researching it. So, while working on a new tessellation algorithm I've been playing around with curve rendering on GPU. The current research is focused on partial specialization - triangulation on the client and pixel position determination (inside or outside of the loop) on GPU. Both vector texture maps and The Loop&Blinn algorithm do that.

Given my position on tessellation on the client, as you can imagine, I'd like to completely skip it and offload it to the GPU. The ideal solution being passing the full path encoded in a texture, then extracting the elements and rasterizing the data using fragment shaders. The problem (or more precisely "one of the problems that bother me") is that we're skipping vertex shaders (due to the fact that we don't have the geometry of the object at that stage) which implies that we need full transformation matrix encoded right along the path plus we need to do the transformation using fragment shaders.

All of that just amplifies my issues with graphics hardware. I wish we could have a decent dialogue with the vendors so I'd at least have an overview of what they are doing. Given my current situation, fragment shaders are so useful when working on physics simulations and reverse engineering full pipeline... Lets just say I'll admire anyone with time to even tackle that. I've been looking for a 15" or smaller (call me sentimental but I really like the "portable" aspect of my laptops) laptop with NVIDIA 7xxx card for the last two weeks. I couldn't find anything besides ASUS A6Vm and A6Km which are impossible to buy anywhere. I'm tired of having to ssh to my desktop to run my simulations so I'd like to have a laptop with decent fragment shaders support and as Dave noted ATI isn't doing too well in that department on GNU/Linux. If you've seen such a laptop let me know as I badly need one, even though I'm crying inside when thinking about spending the little money I've got. Plus I wouldn't mind being able to do something amazing for Plasma on my laptop after I'm done. Your motivation for helping me is the knowledge that most likely the sooner I'll finish this stuff the sooner I'll be back to doing graphics and other weird Open Source things.

Oh, and also I really like Michael's work on -Bdirect and the lack of response his patch generated is a 'little' depressing. I'd love to see this thing go in.

I haven't been blogging for a while. Mainly because I simply haven't felt like it and I've been going through some things lately. But I promised that I'm going to show some movies of things I've been doing. There's really no good way of showing OpenGL effects, vns2swf just doesn't handle it. So those will come later.

Today we're going to talk a little bit about what we can do with ARGB visuals for Plasma. The problem was that we wanted to have custom shaped windows, whose shapes can be animating and anti-aliased. Something XShape can't handle. Therefore we made sure Qt works correctly with ARGB visuals. Now, the big question is "what are you talking about and what can I do with it?". So lets look at an example that I just recorded using vnc2swf (physos did the nice html wrapping of the files so if you post this blog somewhere have mercy on his server and try to mirror the files somewhere):
http://physos.net/zacks_videos/zacks_video_1.html (swf file at http://ktown.kde.org/~zrusin/cool1.swf )
As you can see we have a window shaped like gear, it holds normal Qt widgets (button, checkbox and labels in this case). Also note that after pressing the button we get a "notification" icon beyond our window. All of this is builtin in Qt. How do you get it? Well, you just fill your toplevel with a transparent brush and set its content propagation. Impressed?
Then lets do something cooler. Lets create a SVG file, lets create a widget and set its shape with the result of our SVG rendering (Qt 4.1 has native support for SVG. If I'm going to get more motivated I'm going to blog a little bit more about the funky things I did to QtSvg so I'm not going to go too deeply into SVG support).
http://physos.net/zacks_videos/zacks_video_2.html (swf file at http://ktown.kde.org/~zrusin/cool2.swf )
The coliber is a SVG file, on top of it we slap a QCheckBox and connect it's toggled signal to a label.
I've been talking a lot about future of graphics lately and one thing I always say is that all I'm doing is building a framework on top of which others can implement anything they want. We spent too much time hacking around framework to do cool stuff. Now our framework (X11 and Qt) support it all. Things like dashboard widgets would be now trivial to implement. In fact we can do it a lot better : connect SVG files with ECMA script and suddenly you get a lot more powerful framework. Isn't KDE 4 getting you all excited?