Michael Dominic K.

Hell in Wrocław

2008-05-07T23:35:15+02:00

I’ll be attending and giving a presentation at Libre Graphics Meeting this year in Wrocław.

Title: “Programmer’s hell: working with a UI designer”.

Time: Friday, 14:25.

Lot’s of fun guaranteed, come to feel some hot flames.

Nordea sucks

2008-04-18T17:13:43+02:00

I rarely feel like blogging about personal stuff but today my patience finally went off. Since I switched from Finnish Nordea (which provides excellent service BTW) to a Polish one I'm having only problems. Not the only one being that for two months now they’re unable to send me a banking card for my account.

Today, however, something much more scary happened. When trying to send them email (using their own banking account messaging system) I got this nice failure:

Warning: pg_exec() [function.pg-exec]: Query failed: ERROR: syntax error at or near 
"u" at character 2101 in /www/pglib/libs/c_db_postgres.php on line 106
error: query(): ERROR: syntax error at or near "u" at character 2101 
INSERT INTO cms.tabmail ( sto, ssubject, scontent, sheaders ) VALUES 
( 'solopl@nordea.com', 'produkty i usługi bankowe', 
'Temat: produkty i usługi bankowe...

As garrett pointed out — of all the places you want to see this kind of error, your bank is not one. For those unfamiliar with the problem — it’s esentially an Sql injection bug which, in short, means that your system security is a piece of shit.

Moonlight flicks

2008-03-04T20:46:00+01:00

Miguel has a good status update on Moonlight. Complementing that I recorded a few simple demos presenting current state of our Moonlight trunk.

While talking to friends at FOSDEM I noticed that while everybody pretty much heard about Moonlight/Silverlight, not so many people have actually seen it in action. This is understandable — at the moment building Moon from source is not trivial. Hopefully those little videos will help a little.

Microsoft showcase — a website collecting links to various Silverlight-enabled pages and web apps. Users can browse sites and rate them. Built with Xaml and Javascript. Watch demo / Download high-res avi.

Podium — A dynamic mashup of various news related to US election candidates. Shows some more advanced text-flowing and formatting capabilities. Again — Xaml and Javascript. Watch demo / Download high-res avi.

Surfaces — A very simple surface manipulation/D&D example. Clutter has a similiar demo. Watch demo / Download high-res avi.

This is only a small selection of Silverlight-enabled sites which was easier to record (ie. not using media playback). A bigger list we use for testing is available at Moonlight 1.0 test sites.

Changes of "N"

2008-01-31T23:27:47+01:00

Just a small status update: I recently quit Nokia and joined the new old faces at Novell for a brighter future. Cheers guys! Helsinki folks — don’t despair, you still have Meritahti.

Also, like last year, I’ll be coming to Brussels for FOSDEM this year. Let’s meet!

On GNOME mobile

2007-11-27T00:37:10+01:00

Murray writes about GNOME mobile:

The is currently most obvious in the GMAE (or GNOME Mobile) group, which Jeff insists on controlling, which the board allowed despite knowing what would happen. After almost two years it has produced nothing more than a press release announcing its existence, and that happened six months later than the members wanted.

I don’t think Jeff is to be blamed here first. I don’t know about other players involved but I personally feel that we at nokia simply didn’t put enough effort into GNOME mobile.

This is to be read carefully. We did put a lot of serious work (directly and indirectly) into GNOME and various GNOME mobile components. A lot of those efforts are invisible. Where we so far failed is to make this work standardized, reusable and transparent — what (if I understand correctly) was the original goal of the GNOME mobile.

Hopefully this can be changed. But I don’t think it’s fair to blame Jeff for this particular issue.

GL colorspace conversions

2007-11-17T14:38:05+01:00

A fellow sushi-lover MacSlow was blogging some time ago about various cool things that can be done with OpenGL and video. Mirco writes:

“The remaining things to implement are: using fragment-shaders for the colorspace-conversion too, hooking up some implicit-animation love for switching between different videos.”

I'd like to pick a little bit on the first part of his todo (using hardware-accelerated colorspace conversions).

RGB vs. YUV

Computer graphics is an RGB-world. Every point/pixel on the screen is represented by an intensity of red, green and blue. Any visible color can be coded with a combination of those three values. RGB is the way to specify colors in various drawing API’s, HTML color coding, etc. However — RGB gamut is not modeling well the way human eye works. Our perception has certain characteristics that are not well expressed in the RGB universe. For example — a human eye is very sensitive to changes in lightness (intensity) but is not very keen on noticing differences between dark shades of blue. This is where YUV colorspace kicks in. YUV (just like RGB) can be used to represent any color but the representation is more interesting from the video compression point of view — which is mostly about benefiting from the imperfections in our sight.

In YUV colors are represented by luminance (Y) and two chrominance components (U and V). For example, in RGB the white color is represented with [1.0; 1.0; 1.0] triple while in YUV it would be a [1.0; 0.0; 0.0] set. In a way YUV predates RGB and computers as it’s the format used in the analog TV (the cable essentially contains YUV signals at different bands).

Conversion

The reason why YUV is important is that it’s used as the native format in video compression. The raw (fast) output we get from a modern video decoder is a (some kind of) YUV buffer. YUV can be fairly easily converted to RGB (and vice versa) but it comes at a price. Since it’s a per-pixel operation the processing time gets steep fast. With high-resolution DVD-quality video we’re talking about ~10 million points per second. With numbers like that any operation becomes a bottleneck. Since in the end we somehow need to get the RGB representation, the only thing we can do is delegate the conversion from the CPU to the graphical hardware.

Overlays to the rescue

The traditional way of dealing with this problem was to use overlay capabilities of the graphics board. Overlays are around since long time (way longer than 3d acceleration) and are fairly well established. Overlays, being a hardware capability, allow us to “take over” a certain (more or less rectangular) area of the screen and dump there some pixel data — bypassing the traditional drawing pipeline. The data pushed can be in YUV format. Modern graphics hardware supports all popular YUV formats and the conversion is handled by the hardware.

The limitation of this approach is that the video (overlay) is not really a first-class citizen in the UI pipeline. It’s something that is (simplification here) “burnt over” other elements of the UI. We can’t transform it, we can’t use it in the 3d/2d effects pipeline and it’s problematic (slow) to draw over it (think transparent playback controls drawn over playing video). Overlays are more than enough for implementing standard desktop players but are useless when we want to do more fancy stuff.

For the fancy effects we want to use video as a native texture/source image while still delegating the colorspace conversion to the hardware. OpenGL API/pipeline does not support YUV formats but we can easily fix that with custom GPU code.

YUV formats

One problem with YUV is that it comes in different flavors (formats) and there are quite many of them. FourCC website has a good overview. The good thing is that there are just a couple of popular formats used in practice and the huge rest is mostly exotic or legacy.

Let’s take a quick look at the popular IYUV/I420 format we get from a DivX decoder. It’s a planar format which means that (unlike most RGB formats) the components are not interleaved. We can graphically represent an I420 buffer:

The buffer contains the full Y plane followed by two U and V planes. And here comes the rub — the U and V planes are sub-sampled at half the resolution. So, assuming we’re dealing with a 400x240 video we first get the luminance (Y) plane at full resolution (400x240) followed by U/V planes at half the resolution (200x120). Again, this is because the information about the lightness of the picture (Y) is more important than the information about the chrominance (“colors”) of the video. In other YUV formats it’s common to assign less bits for the U and V.

GL implementation

In the GL implementation we particularly want to:

Avoid any data processing on the software side
Avoid extra mem copies/unpacking of the data
Benefit from the hw-accelerated scaling/filtering (linear, cubic, etc.)
Get a high-quality image

To achieve this we need to use three GL elements which are not part of the GL 1.x standard but are commonly available as extensions — multitexturing, fragment programs and rectangular texture.

Multi-texturing allows us to use three different textures (Y, U and V plane respectively) as the source for the output image. A custom fragment shader executes the proper blending function to create the RGB data out of the YUV source. Rectangular texture is necessary to be able to use non-power-of-two resolution source as the texture.

For the textures/planes we use a GL_LUMINANCE 1-byte texture format. We also need to use a separate set of texture coordinates for each plane due to the resolution differences. The texture-filtering step (ie. during scaling) happens before the shading step so in the shader we automatically get properly filtered data (each texture separately).

For other YUV formats (ie. the interleaved ones) we need to do a bit more work. As the UV components are usually scattered across many triples automatic GL scaling/filtering will destroy our data before it reaches the shader. To counter that we need to first draw (with hw-accelerated conversion) to an off-screen FBO/texture and reuse that data as a native RGB texture for further rendering in the UI/scene. Alternatively one can use pbuffers (less optimal performance-wise).

Source code

Here is an example program + source which renders a sample video (Nokia n810 ad) using GStreamer + hardware-accelerated colorspace conversion and some effects. The example uses a rather primitive way of syncing video using timers. The proper way would be to write a decent GStreamer video sink or extend the existing GL-sink to use fragment programs. This approach would prolly be the right way to handle video in ie. clutter.

A rendering of the program output just for reference (might not show up in RSS, full resolution video can be downloaded here):

Curvy blues

2007-10-27T18:40:45+02:00

I was looking in the past (and some more) at various solutions for efficient hardware-aided curve rasterization methods. Those ideas mostly focused on using the graphical hardware for accelerating the geometry generation process. But what happens, when we completely skip the geometry generation step? Even more blazing performance and totally resolution-independent rendering. Thanks to some tips by Jon and interesting math discussions I had in the past weeks, I'm glad to present my current thinking.

Quadratic curves

Quadratic curves (second-degree polynomials) consist of a starting point, an end point and one control point. Such curves cannot self-intersect nor inflect. The representation of a quadratic curve is a parabola, a straight line or (a degenerate case) — a point. Quadratic curves are not the most popular ones in modern graphical packages. Cubic types (more about them later) are the basic unit of notation. In example, cairo doesn’t provide direct quadratic API. It’s understandable as any quadratic can be trivially represented in a cubic form. However, since (due to their limited properties) quadratics are usually much faster to process it makes sense to look at them separately. Quadratics are part of the SVG standard and have some interesting uses — including TrueType fonts (which are represented only with 2nd degree curves) and Flash (which uses quadratics as the native curve representation and represents cubics by subdividing them into quadratics). Few examples of quadratic curves:

Now, let’s look at how we can hook up the programmable GPU hardware to rasterize quadratics. The first observation is that the three points describing the curve form a triangle and this triangle covers the whole area of the curve. Triangle is the most basicrasterization primitive in modern graphics hardware. Let’s assign two texture coordinates (v and w) for each of the three points. We’re going to use [0.0; 0.5] , [0.0; 1.0] and [1.0; 1.0] for, respectively — the start point, the control point and the end point.

As the triangle is being rendered the hardware will interpolate v and w across the three vertices. For each pixel belonging to the triangle we get a unique, interpolated v and w texture coords pair. And here comes the crucial part — as the actual “texture” for this triangle we use a dynamic fragment program that evaluates the following expression:

If the expression evaluates to true, we pass the pixel. If not, we discard it. What we get is:

Here is a shader implementation that does this operation. As we see, the rastered picture represents the curve we’re trying to visualize. To be precise, we get the fill for the curve. If we replaced the < sign with = sign we would get the actual stroke (the green line). As we zoom towards the curve, the shader generates more pixels giving a more accurate representation. A true resolution-independent rendering.

I'm going to come back to why this is so fundamentally amazing later on, but now let’s move on to the cubics.

Cubic curves

Cubics (third-degree polynomials, the bezier-curves) are a bit more complex. They consist of two arbitrary control points plus start/end points. As a result a cubic can self-intersect, loop, inflect or cusp. Beziers are the thing in vector drawing and most of the data we get to render these days (icons, buttons, UI elements…) are sets of shapes defined by cubic curves.

For blazing-fast rendering of cubics we’re going to use a similar approach that we used for quadratics. Since cubics consist of four points we need more than a single triangle. Actually, depending on the control points set we’re dealing with, we need 2 or 3 triangles. In other words — we need to triangulate the points. In this case (very fixed) triangulation is trivial and essentially we can discover the case we have by doing a few dot products between the vectors of the control points.

Since we’re dealing with a cubic equation, we need three texture coordinates per point (that’s perfectly fine with the OpenGL API). Let’s call those three coords: v, w and t. In our fragment shader (implementation here) we’re going to evaluate the following expression:

And the last hard part — unlike quadratics, for cubics there are no static texture coords to use. We need to calculate them separately for each curve. The method to do that is a subject for a separate article, but it’s enough to say that it’s a fast fixed-time operation that involves few matrix multiplications. Essentially we need to put the control point coordinates in a matrix, move it to power basis and analyze the determinants. Depending on the number of square roots, we have one of the few distinct cubic-cases which further dictate which v, w, t coords to use. Those computations could be put in hardware-accelerated matrix pipeline but I haven’t found that to be critical enough to do so.

In the end we end up with:

Using this technique we can render any cubic at any resolution in a fixed time.

Practical results

Two following screenshots (click for bigger versions) show sample renderings (a font glyph and a mono-project logo) obtained using this method. Shapes consist of roughly 30 cubics/lines. The first figure represents the inner-mesh hardware-accelerated triangulation. The second one — a rendering of the curve data. By combining the two we end up with a final mask for the shape. This method works for any polygon including complex self-intersecting concave/convex shapes.

Why it’s cool

Traditional approaches to curve rasterization usually require recursive subdividing of the curve towards a certain level of line-approximation or reaching a pixel-precision. The complexity/processing time grows exponentially and the result might be not correct. With the approach presented above we achieve high quality by keeping the mathematically-correct (not compromised) information about the curve till the very last step — the rasterization . The precision of the final image (output) is only limited by the resolution of the display system, not the implementation. The complexity of the algorithm is linear and the processing time is only constrained by the pixel fill rate of the GPU board (that value approaching hundreds of millions for modern equipment).
From my experiments, attaching the (presented) fragment shaders to the triangle rasterization process has no any impact on the performance. In other words, it seems that on modern hardware rendering a solid-filled triangle is equally fast as rendering a triangle with a simple shader.
As we’re not generating/storing any extra geometry data and just using two (max three) triangles per curve, the memory requirements are minimal — even for extremally complex shapes.
By using some additional extensions (such as a compiled vertex array) after the initial pre-calculation step we can completely move the geometry data to the GPU unit and render by just invoking display lists. In this case the expose events theoretically come cost-free for the CPU.

Smart curve rasterization is the first step towards efficient drawing API implementation. By combining the solution with additional dynamical GPU-programmable pipeline elements (gradients, triangulation, anti-aliasing, multi-sample rendering) we can achieve blazing-fast vector-based drawing tool. This is my current approach towards building a new OpenGL-based cairo backend. World domination follows. Obviously.

Update: for better math overview check this article by Loop & Blinn. It’s a good starting point even though it’s not complete and has certain mistakes (check comments).

Nokia N810 announced!

2007-10-17T19:41:48+02:00

It’s announced, we did it!

Ari has some more gory details about what’s new and cool. From the toolkit point of view one thing worth mentioning is that we’re now running the full gtk-2.10 stack in Chinook (the OS release powering the n810). Now, there are two things to that:

The bad thing is that due to the consolidation efforts the API compatibility is broken. Let me stress that again: if your application uses UI, it won’t run at all on Chinook without (often trivial) modifications. We have documents and tools to assist you in porting the applications. So go ahead, download Chinook beta and update your app — there is a lot of cool stuff in maemo garage that we need to make run on Chinook also. You can nag us on the IRC channel or mailing lists for help on specific issues. We’ll help.

The good thing is that we’re now very much closer to the gtk upstream and you can expect the toolkit stack to behave in a much more sane and predictable way. We’ll also now be able to actually track the API stability more closely.

As Ari also mentioned, Chinook is going to be available for n800 also. While it’s common for companies to provide firmware/bugfix updates for legacy hardware, it’s pretty rare to get a full new OS release + new features for free. I'm glad we did it since… well… it’s exactly the right thing to do!

Service interrupted

2007-10-14T19:10:28+02:00

I finally manged to go through the maintenance pain and migrated my blog to a completely new system and design. I put effort into making sure that all links & serivces work like they did but in some corner cases the RSS feed might stop working for you. If that happens and you’re still interested in reading, please re-subscribe.

I'd also like to appologize to all people who commented and put their opinions on my blog in the past despite the commenting system being completely bolox. It’s finally fixed now and works as expected.

Sorry for the inconviences. More interesting service to follow.

Vector drawing: OpenGL polygon tessellation

2007-08-16T09:50:39+02:00

After having looked into the hardware-accelerated bezier curve computations I checked something more difficult and closer to the reality: hardware-accelerated arbitrary polygon tessellation with OpenGL. This topic has been covered by Zack some time ago, spawning a lot of flame (as most of the GNOME vs. KDE performance comparisons do). All benchmarks are flawed, of course.

Test case

I used same setup as with my previous experiment. This time I measured the real framerate to make sure that no anomaly occurs due to GL async API. Each frame of the test consists of random flowers being drawn to screen with random parameters. Each flower is a polygon outlined by eight bezier curves. The flower shape is not special/optimized in any way. Any closed polygon made out of any number of curves could be used for this purpose. Summarizing:

Thinkpad t43 with ATI mobility x300 card (fglrx proprietary driver with GL support)
200 flowers being drawn in each frame
Each flower has a random position, rotation, scale and fill
Fill is a linear gradient from a random RGBA color to another random RGBA color
640x480 space is used
Same set of random data was used in both examples
Anti-aliasing was turned on
cairo 1.4.10-1 was used in the cairo version
Source code for the programs

The OpenGL rendering seems to be a pixel “fatter” than the cairo version (prolly a bug in my code). The GL output seems to be slightly brighter blended. I guess the significant difference between cairo x surface performance and cairo image surface performance also comes from the intensive blending.

Optimizations

Some optimizations in the GL code could be made to speed up the code even further:

Computed bezier vertices could be stored (even as compiled vertices, if available) to skip the need to generate them twice for the anti-aliasing run.
As in my prev example, vertex shader could be used to generate bezier points. That would require a different way to get the polygon extents though.
The quality of the curve approximation (detail level) doesn’t seem to affect performance much and could be increased.

Algorithm

To render the polygons I'm using a variation of the stencil-based algorithm described in the OpenGL Red Book. It relies on a 1bit stencil buffer, which is commonly available. The basic method is:

Disable framebuffer, enable stencil buffer & stencil testing.
Draw triangle fans for every vertex in the polygon with an odd-even stencil flip rule.
Enable framebuffer, disable stencil writes, keep stencil testing.
Draw anti-aliased outline of the polygon but only where the stencil bit is not set (those are the anti-aliasing artifact pixels that theoretically doesn’t belong to the shape).
Switch stencil test rule to pass only when stencil bit is set.
Switch stencil write to zero the bit when passed (spares us a separate stencil clear call later on).
Render the actual polygon shape with ie. quad.

Worthy benefit of this approach is that it fits (works with) all the standard OpenGL matrix transformations, depth buffer testing, texturing model etc. It can be easily extended with 2d boolean operations. The CPU is not performing any calculations (except the original path calculation which can be offset to the GPU with a vertex shader).

Once in a while I'm getting questions how did I implement hardware-accelerated video color space conversions in Diva. I'm going to write a bit about that soon along with some boolean operations coverage.

Vector drawing: OpenGL shaders and cairo

2007-08-06T14:52:34+02:00

The mystery

Some time ago I had a chance to talk to Zack Rusin about the differences between QT and the Gnome/Gtk drawing stack. Zack was showing some impressive visual toolkit demos using tiny fractions of the CPU horse power. One of the subjects we started arguing about was using GPU hardware to perform tessellation — as opposed to cairo, where tessellation happens always on the software side. The idea seemed tempting though the practical benefits were unclear to me.

During GUADEC I poked a few people about the possibility of using OpenGL and shader programs with cairo to perform hw-accelerated tessellation. I got some constructive and interesting (yet discouraging) feedback about the problems and complications related to this approach. A lot of those (highly valid) points are summarized by Tim Janik in his blog. Still, the possible gains/performance improvements were highly unclear.

Investigation

I therefore decided to write a small benchmark to see what kind of speed differences we could possibly be talking about. To see if the game is worth playing at all. As the testbed I've chosen one of the most fundamental bits of the vector graphics — a bezier curve drawing algorithm. I implemented a 100% hw-accelerated version as a vertex shader program running on the GPU. I compared it against cairo software version in two scenarios — using xsurface and image surface. The following setup was used for the test:

Thinkpad t43 with ATI mobility x300 card (fglrx proprietary driver with GL support)
A time to draw 100 random (pre-generated) bezier curves was measured
Curves were randomized in a 640x480 space with a random width (1-10pixels) and a random color (red, green, blue, alpha)
Same set of random curves was used in both examples
Anti-aliasing was turned off
An best of 3 test runs was taken
Source code (CG toolkit from NVidia is needed to compile the shader program)

The rough-rough result of the test is that drawing using hardware opengl tessellation is 30 times faster than current software cairo implementation. By overlying the resulting images in ie. GIMP one can see tiny pixel differences between the two implementations (cairo implementation begin prolly more accurate) but essentially it’s the same thing. The OpenGL shader implementation is not optimized at all and could be made faster by using a geometry shader instead of a vertex shader.

Not only about speed

Using GPU to perform things normally happening on the CPU has one additional advantage — it frees the processor to do other things. In my setup, with the cairo implementation drawing random curves as fast as possible, I can get a ~10fps animation (100 curves per frame). This keeps the CPU busy at 100% and the framerate will drop as soon as CPU starts doing anything else.

With my 100% GPU implementation I get around 400fps and the CPU usage never goes beyond the 30% threshold (lots of it being the random-number generation I presume).

Caveats

OpenGL shader program support is not yet a commodity, even though it’s coming fast even to the mobile space (ie. MBX chip having vertex shader support and the SGX chip having a full set of pixel/vertex/geometry shaders support).
As Tim pointed out, OpenGL implementations vary and per-implementation fine tuning might be in order
To efficiently use shader programs one needs a full OpenGL-based drawing stack
Shader programs + math + drawing algorithms are hard
OpenGL drivers suck on Linux

I still think that the results are interesting though. I quickly hacked another shader implementation to draw solid-filled bezier shapes (more about that soon). The performance differences seem to be even bigger. My gut feeling here is that the programmable hardware drawing might be the only way to go for the resolution-independent fully vector-drawn UI’s. Especially on the mobile where the CPU power is scarce, it scales badly, and everything that doesn’t throttle the processor means longer battery life.

GUADEC 2007

2007-07-12T17:42:14+02:00

I’ll be attending GUADEC this year in Birmingham. During the tutorial day (Friday) I’ll be giving a practical introduction to the maemo UI and showing some key differences from the full-blown desktop GNOME interface. If you’re an application developer and you'd like to learn few new quirks about making your software feel responsive and look good on the mobile — please do come.

There is quite a bunch of us from nokia coming to the event including a strong representation of our magnificent three-letter tookit team starring luc, tko, fer, xan and mdk. Great chance to poke us about our future plans regarding hildon, bitch about sardine and discuss some revolutionary UI ideas you might have for the internet tablets. “Hildon — now open more than ever!”. Ehm.

See you in the UK.

Chapter #1 in which we meet Graff

2007-04-23T17:14:22+02:00

Long time, no news.

I'm working now on a (new) set of libraries called Graff. Graff is a lighweight high-performance graphics rendering library. I guess it falls into the category of canvas — as currently discussed on the gtk mailing list. It’s a bit more generic though and focused on providing ways of animating graphical elements over time. It knows about motion paths, timelines, animating parameters, etc. The use case here is building new rich custom UI’s, providing a building-block for higher-level toolkits and abstracting hardware-specific quirks. It provides a basic model-view-controller environment with the UI elements (“faces”) being cleanly separated from the “motors” driving them. “Touches” provide event sources.

Graff can currently render using two runtime-selectable backends — a hardware-accelerated OpenGL backend or a software-only driver. The software backend is extremelly highly optimized using all the ugly demo-scene tips&tricks straight form the ‘90ties. It performs suprisingly well and the demo applications mentioned below can actually run good on our existing hardware (nokia 770, nokia n800).

Speaking of demos, I made a few simplistic test applications to sketch the idea of what Graff can already do. Video recordings available below. It’s a work in progress, early on.

Image viewer: a basic image viewer controlled with thumbs.

Dancing emotes: an example showing objects running along morphable paths.

Scrolling list: contact list with inertia scrolling.

Drag: trivial drag and drop with some smooth blending.

The image viewer example uses Jakub’s nice photos. Icons come from our awsome Tango artists.

Fosdem 2007

2007-02-22T15:01:10+01:00

There is a few of us from nokia coming to fosdem, Brussels. Catch us to chat about gtk, hildon and maemo. Or we’ll catch you.

I also released nflick 0.4.0 — a flickr browser for the maemo platform. Binaries for scirocco and bora can be found at the usual place.

Main changes are:

Adding hw-keys navigation to fullscreen view
Pressing “escape” key while viewing a photo will return to the photo list
Worker dialogs have now proper transiency so they don’t block whole device
Other dialogs have now proper transiency too
Fixing the bad-paging bug for good

Maemo theming

2007-02-13T15:23:55+01:00

A bit old news, but Tuomas recently released a new version of his awesome plankton theme. Judging by the comments on his blog and the screenshots posted on planet maemo, It looks like the theme is liked and appreciated.

I also find tigert’s theme aesthetically pleasing and nicely-balanced. It reminds me of a well-formed piece of metal that just feels good in the hands. This is, quite unfortunately, in contrast to default n800 stock themes that remind me of disco mirror balls and DDR.

I sometimes have a feeling that the psychological effect of good theming artwork (understood as well-drawn artwork) is underestimated. After all, this is what the user of the product is going to be living with on a daily basis. It’s the face of the device. It can cover-up for many shortcomings of the software or badly expose them — very much like a pretty-faced girl can often cover up for a plump figure (it doesn’t seem to work the other way round, does it?).

For developing the themes we created a system that decouples the layouts from the actual graphics. The layout contains the common gtkrc styles and other internal bits shared among all themes. The graphics consists of a single template file that can be easily handled by the artist. A set of tools can be used for various helper tasks.

This dual system is very much similar to the libraries vs. applications in software development. Library (layout) contains some common bits shared among all applications (themes).

The only things missing in this system is some documentation — so that someone can actually use it. Coming soon.

Mono on maemo

2007-02-04T14:56:00+01:00

I've created some tarballs and a wiki page describing the process of getting mono to work on nokia 770/n800. The solution is a bit dirty & temporary — but works.

The biggest limitation now (besides the packaging) is the lack of working Hildon C# bindings. If someone would like to improve the situation, please work against the new hildon 1.0.0 branch which should work smoothly with the gapi parser.

Comments are welcome on our mailing list .

Clone wars

2007-01-28T09:40:00+01:00

On the above four screenshots one can see a simple mono application running in four different environments — windows xp, linux, nokia 770 and nokia n800. The binary has been compiled once and executed without any changes on the four different platforms.

The application in question (MonoEye) is a somewhat more advanced “hello world” — it’ll show a random picture of whatever the user enters in the entry box. It does so by picking up a random photo from flickr that has a given tag applied. So, when you enter ‘monkey’ you get a random photo of a monkey. Actually, sometimes you get other strange results — apparently some people are ~~sane~~ weird enough to tag their girlfriend photos with a ‘monkey’ tag.

In any case this simple application does something “real” and useful: A little bit of network http access A little bit of regexp for RSS parsing A little bit of threading (the photo is downloaded in a separate thread) A little bit of gtk

…and all this stuff works nicely on all the four mentioned platforms.

I don’t think being cross-platform is the biggest advantage of mono, but I smell some interesting opportunities here.

M is for monkey

2007-01-21T15:37:00+01:00

A while back lupus did a great job of porting mono to run on arm. I did some raw experimenting over the weekend and managed to get the whole C# gtk stack running on the N800. The initial impressions are very positive — pretty fast startup time, low memory usage.

Since now all the bits are figured out, the only thing left to do is the boring task — correct packaging & handling of the whole debian mono tree. We clearly need a real hero here…

Next step: moon

2007-01-08T15:56:00+01:00

Nokia N800 is out, we just released it!

This is not the most sexy-looking babe in town, but she has a lot of punch and she’ll get you through the night, the day and all the other horrible stories. YouTube works, skype is coming. The gorgeous high-resolution display rocks hard and is easily the best display in this kind of consumer electronics.

Oh, and there is a developer program availible so that all the naughty kids that like to tinker with things can get a device for a mere 99 euros. 500 devices are available this way. That’s a lot I'd say!

Maemo kicks. Join now.

State of Diva

2006-12-07T14:49:00+01:00

Over the past few weeks I received a lot of questions regarding the state of the Diva project. I’ll try to address them here in a slightly broader context.

It all started with a goal to create an an easy to use, “just working” solution to video editing on Linux. It started “high up” — as I personally think that our community is now too mature and too creative to just copy solutions seen elsewhere. It’s worth trying to aim high, instead of believing in the magic of incremental approach.

I spent a lot of time and sweet during the past year hacking on Diva and trying hard to get it working. To some degree it was a success — some ideas turned out really well, the overall application design & UI is something I'm very satisfied with. Unfortunately, the core video muscle powering Diva was one of the bits that never really worked as expected.

There were at least two “major engine rewrites” involved — adjusting to changes in the gst framework, trying out completely different approaches. It has been a great learning experience and a fun ride. There comes a time however, when you realize you have to stop banging your head against the wall, look around and get a bit more real.

Over the past month I was trying to wash my head fresh and get out of the “burned out” state towards the project. I realized that I still want to work on this stuff, even though my clock runs for other cool projects too. I still feel like trying to get it done, but I don’t want to repeat any mistakes. It’s a shame, that you have to screw the thing many times to learn how to do it right.

I'm going to start with replacing GStreamer with another framework. Experience tells me now, that (your mileage may vary) GStreamer cannot be used directly to build an advanced video editor. GStreamer is a powerfull framework, and I personally have a big professional respect towards people who hack on it — they deal with an extremely complex matter. GStreamer solves a lot of problems on the GNOME desktop but it doesn’t solve the problem of video editing.

Gst is a playback framework, and for video editing you need editing framework. The later is not, as it’s commonly believed, just a superset of the former. The MLT framework is an interesting example of the “video editing” architecture.

Only one thing bothers me — there are so many people who sent me nice and encouraging comments about the project, but somehow it doesn’t translate well into code contributions. I used to think this is related to the fact that multimedia is just darn scary and there are not many people who want to deal with it. But recently I realized, that maybe it’s just my fault of sending the wrong community “signals”. Therefore, I want to make one thing clear:

Your help and skills can make this thing happen. This is open-source, let’s do it together.

PS: The diva-project website (http://www.diva-project.org) is down because of a dos attack. I believe this is random net stuff since we had some wild spam attacks in the past. But in case someone has something to say — please, you have to make the message more clear. I'm not getting it.

I hope it’ll be back soon, but in any case — the subversion server is up and running, the diva sources can be accessed as usual on http://svn.diva-project.org/diva/.

NFlick 0.3.0

2006-11-26T16:42:00+01:00

It seems one of the more annoying limitations of NFlick was it’s inability to display photos that don’t belong to any photoset (unsetted photos). A lot of flickers don’t use photosets at all, and for them NFlick wouldn’t show a single photo. Not good.

So I did a little bit of work and the just-released version 0.3.0 addresses this issue.

Other new features include: * A slightly "hildonized" UI look & feel. * Informational dialog about the cache size. * A possibility to clear the cache. * Menu option to reset (remove) all private data stored. * Cache can be disabled. * Maemo-launcher is being used for faster startup. The usual collection of links: * [NFlick 0.3.0 binary package](http://files.mdk.am/packages/nflick_0.3.0_armel.deb) * [NFlick 0.3.0 source package](http://files.mdk.am/releases/nflick-0.3.0.tar.gz) * [Subversion repository](http://svn.mdk.am/nflick) * [Troubleshooting & suggestions](http://groups-beta.google.com/group/nflick) NFlick is a side-project of mine, but [tigert](http://www.tigert.com/) has this neat idea to turn your [770](http://www.nokia.com/770) into a [flickr](http://www.flickr.com) photoframe that cycles through the recent photos posted by your contacts. It would sit quietly on your desk (connected to power & net obviously) and light-up when new content is available. I hope we'll sit down to it at some point.