Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: I guess that means SDL cant run on a raw framebuffer. It can. The problem is that it's not the only process running. Think what would / should happen if user presses power menu while game has switched to another VT... It would switch back to X VT ? Isnt that what you want ? i.e systemUI or whatever could manage this. I think Daniel has also mentioned some (kernel) race conditions in switching VT. Doh! I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Markku Vire [EMAIL PROTECTED] wrote: If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. If the games need everything an xserver provides then this could be another option (if a little more extreme =)) -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Matthew Allum wrote: I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. Windows that are not visible should not be updated, so there shouldn't be any need for Xft to regenerate the font bitmaps for text output. For banners getting pixelwise smaller text would actually be better as then it's physical size would be right (just not the borders). :-) For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. Note, this was just one potential problem - and with any problem theres going to be somekind of workaround. Its just special casing everything to 'subvert' randr is going to need alot and therefor I dont see what you gain from using randr to do it ? And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? No idea I guess this would be toolkit dependant. (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) MB does not unmap windows unless they are minimised. It would be trivial to make it do so however. Any comments on my 'simple' non vt switching solution without randr ? It would be fairly easy to simulate in Xephyr if thats a worry btw. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/2/07, Eero Tamminen [EMAIL PROTECTED] wrote: It's evil that games change screen resolution, system changes should be controlled by system software instead of random apps. If it's enough that the whole screen is scaled instead of a window or specific update, for Maemo the XRandR approach could be joined with my earlier proposal. I.e. if window has certain property (say geometry=320x200), the window manager could use XRandR to switch the screen resolution when that kind of a window is on top/focused/fullscreen(ed). When the window is not anymore focused/top/fullscreen or is closed, the previous/default resolution is restored. This way banners above the window wouldn't get the resolution changed (banners don't take focus), but dialogs (like power menu) would. Do you see any problems (besides getting these changes to Matchbox and SDL after adding XRandR support to Xomap)? Theres a big downside to this approach in that matchbox already supports randr and has done for a while in order to facilitate stuff like screen rotation - matchbox will in effect resize all windows and position dialogs as to adapt to the new screen resolution - like other WM's also do. This is what you'd expect in the general case. So if you pixel double via randr every single application is going to get resized and un resized. Whats worse is theres not going to be an easy way around this as much stuff in matchbox is obviously dependant on the 'real' display geometry. For the use case which is being described here - namely always full screen applications which need exclusive access to the display at a lower resolution Why not do something like switch to another VT and do it directly on the framebuffer ? and then wrap this with something that makes sure you can always safely return to/from X - maybe something managed through systemUI or some such. This is a different approach but could prove simpler in the long run though I havn't thought long and hard about it so there could be some obvious downsides - More a random idea :) -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hey; On 4/11/07, Sean Luke [EMAIL PROTECTED] wrote: Hi; On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote: For the moment I'm experimenting with various floating windows for various utility functions -- my drag-and-drop example on my N800 website, say. Do you have an URL? cs.gmu.edu/~sean/stuff/n800/ Aha. If it newton style clip board you are trying to copy - I think the way to do it would be something like; - When copied text is dragged use an override redirect window or potentially even better change the cursor image to represent the copied text (not sure if this is totally possible - would need some experimentation). You'll need to move the window yourself (no big deal). - When this window reaches a screen edge, unmap it and the remap a dialog window with the following set; o no decorations. o transient for root o _NET_WM_ABOVE hint set . (this may not be needed) - For pasteing / moving repeat / reverse the process. You could also potentially handle resizing if need be. That should hopefully do what you want and work fine with MB. -- Matthew ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi; On 4/8/07, Sean Luke [EMAIL PROTECTED] wrote: Anyway, I whipped up the following little program below as a test and low and behold I can get the window to drag around BUT it creates all sorts of artifacts: screen tearing, a bizarre window flashing in the top-left corner, and slow updates. The flashing in top-left corner is a matchbox bug affecting moving decoration-less dialogs. It was fixed a little while ago in matchbox svn (2007-02-17 in ChangeLog) but I guess thats maybe a little later than whats on the device. In terms of the screen tearing and slow updates Id guess thats probably an issue with moving the window a little too fast for what the h/w can handle (the screen tearing suggests you are moving them very fast). -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] radio?!
On 2/7/07, Andrew Flegg [EMAIL PROTECTED] wrote: A user suggests it is: http://maemo.org/pipermail/maemo-users/2007-February/003605.html The repoository link did work well for me. Furthermore ive tested the fm-radio app from o-hand.com rep. Didnt ever know that it is possible to hear radiio with headset connected. However, I can't see an fm-radio app in the Opened Hand repo from looking at Packages.gz. Um, I dont know where this confusion is coming from, but we at OH have never written an app called fm-radio (or even heard of one). We know nothing about the radio. Sorry :( -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Discussion of a possible project - offline calendar project
Hi; On 1/15/07, Andrew Flegg [EMAIL PROTECTED] wrote: On 1/15/07, Martin Grimme [EMAIL PROTECTED] wrote: [development of another PIM suite] This sounds really interesting. I know that there are already applications like dates or GPE-calendar for the N770 but both don't fit my needs. Since my idea was to write some sort of PIM suite specially for the 770 in the near future, maybe we should join efforts. I don't think GPE is the perfect PIM suite (it is the most mature we've got, though) and Dates is still very immature. However, is what you want so diametrically opposed to the aims of these two projects that you couldn't work with them to improve the existing projects, rather than creating another? I guess though similar on the surface in what they do, they are actually very different in how they go about things. For example Dates, unlike GPE-cal(afaik), uses a client-server split and attempts to align itself more with, and reuse, desktop technologies in having an optimised EDS backend (which actually gives *alot* for 'free but not of all that functionality used as yet ). We also wanted to experiement a bit with the UI as to at least try and come up with something workable but original that didn't follow the kind of standard PDA calendar app blueprint. If it's a case of getting in at the ground floor, the relative youth of Dates might be more interesting to you; and there are some nice UI ideas in there which will only improve with decent synchronisation. I don't know the people at Opened Hand responsible for Dates, but I can't believe they wouldn't be interested in the help? Especially from two talented, enthusiastic programmers. Of course help is always welcomed, Bugzilla; http://bugzilla.o-hand.com/buglist.cgi?product=dates is a good place to start. Just as a note, Dates is still being developed (we recently released 0.2 for example and have bora packages - maemo.o-hand.com ). We have basic syncing (This is infact where we have been currently focusing, admittadly limited ,attention) just not quite at release quality as yet. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] GTK2.8 ??
Hi; On 7/20/06, Koen Kooi [EMAIL PROTECTED] wrote: Maemo already uses softfloat and it's still slow. Right, FPUs exist for reason. If softfloat was perfect they wouldn't. You still take a hit, just not as much as hardfloat. Also I dont think its just FP causing a slowdown though this appears to be particularly nasty in pango-cairo GTK+ usage ( see below referenced thread ). Don't count on it, Carl has had a long history of playing with arm based machines, even before cairo was started. But we'll see, but I won't have high hopes, even if I *really* like cairo. There is some movement on the GNOME performance list - See the 'Floating point in pango' thread. Archives are broke so see http://thread.gmane.org/gmane.comp.gnome.performance/ Please get involved if you think you could help. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] keyboard notes
http://maemo.org/pipermail/maemo-developers/2005-December/002016.html may help a little. On 1/14/06, Brad Midgley [EMAIL PROTECTED] wrote: Hey I do like the wireless keyboard overall (stowaway model). The caveats are probably well known... - activate the keyboard with something other than the xterm in the foreground or switch between apps once (enter key won't work) - backlight is dimmed and then turned off in spite of typing activity - not a lot of global keyboard shortcuts? only alt-tab as far as i can tell - the icon image should be a keyboard in combo with the bluetooth icon so it's clear what thing is connected over bluetooth Brad ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi; On 1/9/06, Eero Tamminen [EMAIL PROTECTED] wrote: Oh and its svn only :( See; http://svn.o-hand.com/repos/matchbox/trunk/matchbox-keyboard/README Is there something preventing releasing it? :-) Yes, layout does not work as good as it should for small displays ( 240x320 ). I wanted to fix this before release. and launch it when the program itself is started? To make an input window work in maemo env ( this is different to defualt mb input win handling ) you need to have it set its transiency to the window its entering data for. I think this would be undesirable as then the application window would be resized. This discussion was mostly about stuff like SDL games which don't handle window resizes. Therefore the input method should be above the application window, not make it to resize. I dont think this can be done currently. best bet would be to XEmbed mb-kb directly in app for this kind of thing. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi; Have you tried setting the StartupWMClass key of the apps .desktop file to whatever ace of penguins sets as its WM_CLASS window prop to ( you can find this out with xprop ) ? If it dont set it, you may have to hack ace of penguins so it does. -- Matthew On 1/4/06, Mark Arrasmith [EMAIL PROTECTED] wrote: Because the 770 uses X11 I was interested in porting some X11 and fltk apps for fun. I compiled Ace of Penguins ( http://www.delorie.com/store/ace/ ) for the 770. Ace of Penguins is a X11 based card game suite that includes solitaire, freecell, taipei, and others. Basically it is the same thing I did with the Agenda VR3 with I got that years ago. So anyway, solitaire runs very fast (it is up and running as soon as the stylus leaves the screen) and is only 80K. But, it doesn't show up in the left toolbar when running. Which makes minimizing it kind of worthless. I have the X-HildonDesk-ShowInToolbar=true set in the .desktop file. Is there anything else I need to do? - mark -- A career is great, but you can't run your fingers through its hair. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] non-maemo apps in toolbar
Hi; On 1/5/06, Eero Tamminen [EMAIL PROTECTED] wrote: As to the input method, maybe the program could depend from xkbd (AFAIK doesn't support unicode, but as it works by synthetizing key events with XTest extension it should work with all X programs) Xkbd is dead dead dead. Use matchbox-keyboard instead ( its a complete much needed rewrite ), it supports full UTF8 but lacks a couple of minor things like images on keys and themeing. Oh and its svn only :( See; http://svn.o-hand.com/repos/matchbox/trunk/matchbox-keyboard/README and launch it when the program itself is started? To make an input window work in maemo env ( this is different to defualt mb input win handling ) you need to have it set its transiency to the window its entering data for. matchbox-keyboard doesn't do this. but you could just embed matchbox-keyboard via XEMBED in some kind of wrapper of your toolkit of choice that handles the transiency or just avoid input windows all togeather and embed it direct in your app. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] ipkg vs dpkg
Hi; On 11/29/05, Russell Nelson [EMAIL PROTECTED] wrote: Matthew Allum writes: Surely this isn't a fair comparison as the packages in Debian 2.2 arn't 'tuned' to embedded use ( i.e include docs, .la files etc etc ). You'd be better comparing udebs that make up D-I or something. I'm only talking about the overhead of the package manager, not the contents of the packages themselves. Okey, but surely some of the metadata you've measured is dependant on whats actually in the package ? Also I dont know how you make numbers out of ipkg's lack of any real maintainership, constant instability ( likely due to former ), wierd versioning scheme, memory issues and horrific 'UI' ( see ipkg -h ). Those are problems with ipkg, to be sure, but dpkg has its own usability issues, and needs a front-end (apt-get) to have ipkg's functionality. Agreed. There is no really great package manager for a small-storage system. Agreed. How do we get there from here? Somebody writes something new that kicks arse and addresses the issues with dpkg and ipkg. PS; note; Im not saying dpkg is ideal for embedded systems here, just that ipkg is not ideal either ( maybe it used to be but not so much nowadays ). Repeat after me: the 770 is not an embedded system. It is a small computer with neither a qwerty keyboard nor a big hard drive, nor a really fast processor. the 770 is not an embedded system - OK :) You understand my point though - we could argue all week on if my digitial watch for example was a small computer or an embedded system. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Stuff to make h/w bt keyboards more useful
Hi;
I recently bought one of the Nokia BT keyboards for my 770. Tomas's
btkeyboard-plugin rocks but I soon got pretty frustrated at the 770
not registering keypresses as activity to stop the display from
blanking.
Attached is a patch to btkeyboard-plugin which attempts to remedy
this. It works rather brutally via sniffing out x keyevents on
currently active windows and calling the equivilent of
osso_display_blanking_pause() for each key press, keeping the display
lit for another 60 seconds.
There is no doubt more efficient ways to do the same thing lower down
the stack. But this was quickest way for me todo and suit my needs.
Also attached is a matchbox keyboard shortcut config file. Put this
file in /home/user/.matchbox/kbdconfig, then run matchbox-remote -k.
This sets up keyshortcuts for 'tabbing' between windows,
fullscreening, closing apps and a couple of other things ( check
kbdconfig for details ). YMMV with these shortcuts as matchbox key
shortcuts arn't totally integrated into maemo.
Finally attached is an xmodmap file. This is relevant at least for the
Nokia BT keyboard and may need editing for other makes. It basically
switches the caps and ctrl keys, makes 'del' a backspace and maps the
non functional 'blue' keys to page up, page down and home.
Put this file in /home/user/.xmodmap. Remap keyboard via 'xmodmap
~/.xmodmap' ( patched btkeyboard-plugin runs this command on new
keyboard connection ). I've put an ARM binary ( from Debian ) of
xmodmap here;
http://butterfeet.org/maemo/keyboard/
( Also togeather with a patched built binary of bt-plugin.so etc. )
All this is very much hacker orientated and really aimed at those who
know what there doing. Try at your own risk. At least for me it makes
the keyboard a little more useable.
Regards;
-- Matthew
--- btkeyboard-plugin-0.2.2.orig/bt-plugin.c 2005-09-21 08:59:50.0 +0100
+++ btkeyboard-plugin-0.2.2/bt-plugin.c 2005-11-28 19:30:33.0 +
@@ -28,6 +28,13 @@
#include glib.h
#include gdk/gdkkeysyms.h
+#include gdk/gdkx.h
+#include gdk/gdkevents.h
+
+#include X11/X.h
+#include X11/Xlib.h
+#include X11/Xatom.h
+
#include libintl.h
#include locale.h
#include unistd.h
@@ -74,6 +81,11 @@
NUM_PIXBUFS
};
+enum {
+ CATCH,
+ RELEASE
+};
+
typedef struct
{
HildonStatusBarItem *item;
@@ -89,6 +101,8 @@
gboolean button_released;
gboolean connected;
gboolean searching;
+Atom atom_net_active_win;
+Window last_active_win;
} PluginInfo;
/* Hildon Status Bar plugin API prototypes */
@@ -99,6 +113,184 @@
gint bt_get_priority(void *data);
void bt_update(void *data, gint value1, gint value2, const gchar *str);
+void set_key_events (Window win, int mode);
+
+static GdkFilterReturn
+x_key_event_filter (GdkXEvent *xevent,
+ GdkEvent *event,
+ gpointer data)
+{
+DBusConnection *conn;
+DBusMessage*msg = NULL;
+DBusError dbus_error;
+dbus_bool_t dresult;
+
+if (((XEvent*)xevent)-type == PropertyNotify)
+return GDK_FILTER_CONTINUE;
+
+/*
+ * This is basically osso_display_blanking_pause(), execpt
+ * we have no osso_context_t... but we do have the source
+ * for osso_display_blanking_pause() :)
+*/
+
+#define MCE_SERVICE com.nokia.mce
+#define MCE_REQUEST_PATH/com/nokia/mce/request
+#define MCE_REQUEST_IF com.nokia.mce.request
+#define MCE_PREVENT_BLANK_REQ req_display_blanking_pause
+
+dbus_error_init(dbus_error);
+
+conn = dbus_bus_get (DBUS_BUS_SYSTEM, dbus_error);
+
+msg = dbus_message_new_method_call(MCE_SERVICE,
+ MCE_REQUEST_PATH,
+ MCE_REQUEST_IF,
+ MCE_PREVENT_BLANK_REQ);
+if (msg == NULL)
+return GDK_FILTER_CONTINUE;
+
+dresult = dbus_connection_send (conn, msg, NULL);
+
+if (!dresult)
+{
+dbus_message_unref(msg);
+return GDK_FILTER_CONTINUE;
+}
+
+dbus_connection_flush(conn);
+dbus_message_unref(msg);
+
+
+return GDK_FILTER_CONTINUE;
+}
+
+void
+set_key_events (Window win, int mode)
+{
+ Window root_win, parent_win;
+ unsigned int num_children;
+ Window *child_list;
+ Status status;
+ GdkWindow *gdk_wrapper_win = NULL;
+ int i;
+
+ if (win == None)
+ return;
+
+ gdk_error_trap_push();
+
+ status = XQueryTree(GDK_DISPLAY(),
+ win,
+ root_win,
+ parent_win,
+ child_list,
+ num_children);
+
+ if (gdk_error_trap_pop() || status == 0
+ || num_children == 0 || child_list == NULL)
+ return;
+
+ for (i = num_children - 1; i = 0; i--)
+ {
+ gdk_error_trap_push();
+
+ gdk_wrapper_win = gdk_window_foreign_new (child_list[i]);
+
+ if (gdk_wrapper_win != NULL)
+ {
+ /* Monitor the window for prop changes */
+ if (mode ==
Re: [maemo-developers] ipkg vs dpkg
Lies, damn lies and statistics :) Surely this isn't a fair comparison as the packages in Debian 2.2 arn't 'tuned' to embedded use ( i.e include docs, .la files etc etc ). You'd be better comparing udebs that make up D-I or something. Also I dont know how you make numbers out of ipkg's lack of any real maintainership, constant instability ( likely due to former ), wierd versioning scheme, memory issues and horrific 'UI' ( see ipkg -h ). Regards -- Matthew PS; note; Im not saying dpkg is ideal for embedded systems here, just that ipkg is not ideal either ( maybe it used to be but not so much nowadays ). On 11/26/05, Russell Nelson [EMAIL PROTECTED] wrote: Instead of tossing out opinions, let's look at some numbers. I have Debian 2.2 on a server and Familiar 6.2 on a handheld. Since we're talking about using either dpkg or ipkg on a jffs2 filesystem, all space consumption is given as so: packagessize bytes/package ipkg total 378K available939 317K 388 installed14761K 415 dpkg total10620K available 15272 8660K 567 installed301 1860K 6180 Here's how I got these numbers: ipkg total is: tar cfz - /usr/lib/ipkg | wc -c ipkg available is: tar cfz - /usr/lib/ipkg/lists | wc -c ipkg packages installed is: ipkg status | grep ^Package: | wc -l ipkg available packages is: ipkg list | wc -l dpkg total is: tar cfz - /var/lib/dpkg | wc -c dpkg available is: tar cfz - /var/lib/dpkg/available* | wc -c dpkg packages installed is: grep '^Status: install ok installed' /var/lib/dpkg/status | wc -l dpkg available packages is: grep '^Status:' /var/lib/dpkg/status | wc -l -- --my blog is at blog.russnelson.com | Crynwr sells support for free software | PGPok | There ought to be a law 521 Pleasant Valley Rd. | +1 315-323-1241 | against calling for more Potsdam, NY 13676-3213 | Sheepdog | regulations! ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] N770 hardware key bindings
I believe your right, I think the home key is trapped by something else before it even reaches X let alone MB. Not sure why that is. --- Matthew On 11/24/05, Luca Donaggio [EMAIL PROTECTED] wrote: Hi, how can I change the default behaviour of the N770 hardware keys? For example: I would like the 'Home' button to cicle between opened applications; I can do that by creating the .matchbox/kbdconfig with 'F5=Next' in it, but after doing the proper action, it still keep on jumping to the 'Home' app., as if the F5 key press event was trapped by something else than the matchbox wm. Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
On 10/28/05, Kalle Vahlman [EMAIL PROTECTED] wrote: I was going to test it with different xlib surface size but since the older SW did not allow me to kill matchbox without rebooting the whole thing and matchbox is kind enough to maximize the window regardless... You cant make the test window a dialog or even a nasty overide redirect ? Last time I checked matchbox only 'maximises' application windows and supports many other window types than just application ones -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Cairo benchmarking
Hey; Though internally cairo is mostly fixed point, its api is floating point - the 770 ( like most ARM devices ) lacks an FPU and thus any FP operations ( especially with hardfloat ) are slowww and really should be avoided. Also as yet cairo isn't heavily optimised and without any kind of supported h/w acceleration cairo operations can be very cpu intensive especially on a relatively large display. -- Matthew On 10/27/05, Kalle Vahlman [EMAIL PROTECTED] wrote: Hola list!I started to write a little Cairo animation to better introduce myselfto the wonders of it, and thought I'd do a little Cairo benchmarkingwith it on the 770.The setup:Compiled cairo 1.0.2 with vanilla settings, and copied to the device.Compiled my demo with -O3The device was not the latest HW nor SW, so the results might be a tadworse than they are on the current devices. Haven't rerun the benchmark yet on newer devices.The demo:It consists of: - creating a XLib surface from the X window - creating image surface for background (only on startup) - copying from that to a buffer surface to clear bg when drawing - drawing a simple shape with lines and few bezier curves on the buffer surface - copying the drewn areas to the xlib surfaceI don't know if this is the most efficient way to draw with cairo, Imight be doing something foolish here and slowing down the process (please say that I do?-).The results:Not that convincing.I ran the demo with 1, 5 and 10 objects drawn simultaniously, and theFPS calculated from those are 5.71, 2.6 and 1.51.So nowhere near smooth animation. I tried to compile the cairo with the softfloat toolchain inscratchbox but that made cairo refuse to draw anything (not sure whatgoes wrong there), although it doesn't crash or complain.The timings for the last three items in the above list tell that the slowest parts are (not suprisingly) the item drawing (0.048s per itemconsistently) and the transferring to the xlib surface (0.099s for 1item, 0.115s for 10 items).Intresting note is that the xlib surface transfer is apparently well buffered, and does not grow linearily with the item count. Still theinitial hit is big enough.This is of course presented in the context of animation, but I thinkthat if you can't do smooth animation (somewhere between 10-15FPS) with simple objects, it won't be fast enough for UI either.The biggest bottleneck seems to be indeed the object drawing (I'dguess the beziers are to blame), but I intend to test drawingdifferent types of elements once I get the time, plus a better profiling of what's taking so long and where.The test results are attached, as well as the demo (the code is littlemessy and contains excess stuff as it's been evolving).--Kalle Vahlman, [EMAIL PROTECTED]Powered by http://movial.fi___maemo-developers mailing list maemo-developers@maemo.orghttps://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
