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.

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!

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.

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.

The mystery

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.

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.

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