Apparently, ABC local news did a short story that included the new OpenMoko user interface we at OpenedHand designed and implemented. I guess that’s sort of fame by proxy, as long as you are in the know!
But hot on the heals of the pixmap theme, I’ve already started work implementing a GDK based theme engine for OpenMoko. The main reason being that the Neo1973 lacks an FPU so performance is hit by scaling all the pixmaps. I could use cairo rather than GDK, but unfortunatly cairo performance isn’t much better than the pixmap performance. It’s still in very early stages, but it makes for a much snappier user interface. If anyone has any tips on reducing the banding in the gradients, I’d be interested to hear them (the display on the Neo1973 is only 16bpp).
12 thoughts on “(Partial) TV Fame”
Hi Tomas, I and Andrunko, already started studying cairo and pixman to make some otimizations in the code for armel and X with 16bpp, because we have the same problem in N800 devices.
There’s code in GDK (GdkRGB to be precise) that does 16bit dithering. You could use this in one way or another. One way would be to do your images in GIMP, display them on a 16bit display and take screen-shots of that 🙂
Have you looked at AGG (Anti Grain Geometry: http://www.antigrain.com)? It is used in the GTK2 (CVS) version of roadmap (roadmap.digitalomaha.net) and has very good antialiasing, blending, etc… – it is also pretty fast – not sure if it would otherwise meet your needs.
I know, it’s not the subject.
But, why button on first capture is ugly ? (Profile button).
I have the same problem in Poky Linux, is it a problem from GTK+ ?
Nice, but the virtual keyboard signs are way too small (they are even smaller than the application font). There are too many wasted pixels in there, you should make the letters bigger.
You could see this ‘iPhone Human Interface Guidelines’ if you want, is very interesting…
I think it wold be good if someone in the OpenMoko team get inspired by that interface guideline. of course, i’am not telling that open moko should be exactly like the iPhone.
Rather than rewrite the world due to lack of floating point to scale pixmaps, why don’t you pre-scale the pixmaps at build time so that they can just be rendered as bitmaps? And then, if necessary, fix the code that renders them so that if the scale is 1:1 it doesn’t do any fancy floating point math? This seems more productive than reimplementation.
The banding can be greatly reduced by applying a film grain or similar (scatter HSV with hue set to zero) it breaks up the bands of colour but keeps the gradient.
Banding -> Floyd-Steinberg dithering and whatever newer variants apply (showing my age here).
This is very interesting. It isn’t obvious to me why Cairo should be better for environments where FPU can be a bottleneck (e.g. neo1973 or multicore.) Does Cairo use integer math in all of its scaling operations?
/me goes to look at gdk and Cairo source.
Comments are closed.