Re: [maemo-developers] Re: testing pango with 770
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clemens Eisserer schrieb: It's disappointing that with every release gtk gets slower... I absolutly agree - GTK-1.2 has been a nice and fast toolkit but since the jump to 2.0 GTK is just one of those too-bloated-to-be-tuneable pieces of software no one wants to touch since it could break something. And do not argue that big, feature richt toolkits are slow in general - Even large QT apps are snappy and very responsive whereas many large GTK-2 apps tend to be unuseable on slower systems (like my Dorun-800). 800mhz to render some buttons and layout texts?? Maybe I am just too old to understand whats going on :( A very favourite argument is that skinned toolkits are slow or X is slow, but how do other, much faster toolkits face with that. Have you ever tried recent GPE on a 200MHz iPaq? I find that very snappy too and it uses GTK2... The latest GTK release uses Cairo for rendering - which is nice in general but really a performance hog. But this is only in the very latest release. I hope and guess that this problem has already been recognised by the GTK developers and they hopefully work on it. I would like to have Cairo as a compile time option and not a fixed dependency. For small devices like the 770 or other PDAs you could then go without it (or slower devices). lg Clemens Cheers nils faerber - -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDsnsQJXeIURG1qHgRAiofAJ9MNGan2jE43nnM0tkz7uKy19P9gwCghrvR P/NKx8hENuZStXB36YJ3NjE= =Ue2C -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: testing pango with 770
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clemens Eisserer wrote: It's disappointing that with every release gtk gets slower... I absolutly agree - GTK-1.2 has been a nice and fast toolkit but since the jump to 2.0 GTK is just one of those too-bloated-to-be-tuneable pieces of software no one wants to touch since it could break something. This thread is pretty funny. Nokia tests 1 version of gtk with different versions of pango and suddenly people say that *different* versions of gtk were tested and jump to conclusions Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDsoXtMkyGM64RGpERArTqAJ9mRUbj319IHPfzaThsxgTEmhrbigCgq+H+ z7vbZmBclp2XCeKnkr+Nvu8= =gn8L -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Irrelevant comparisons (was Re: testing pango with 770)
Hi agani, wow this seems to develop to a real flamewar ;) I think it's useless to compare things that don't have the same features. If something doesn't have a required feature, all of its apparent speed is useless. (Note: Qt v2 is something you could feature-wise compare to current Gtk, but e.g. current Qtopia is based on Qt v2.) This is the default it has soo many features so it is slow and there's no way arround that argument. I did not compare QTopia with GTK since those are quite different things, I spoke about QT-4 vs GTK2 on top of an Xserver which has not to do a lot with handhelds but with toolkit performance in general. Because of first, yes, it's faster, but it's also unusable un-professional looking due to flickering drawing (check e.g. how awful menus in Gnome 1.x look) and crappy looking fonts. Hmm, yep it flickers but on the other side resizing windows or sub-windows is incredible slow with GTK2. QT4 is quite good when it comes to dynamic layouting and includes almost everything (or even more) which is built into GTK2. Pango is also a known bottleneck, but without it the Gtk users would be restricted mostly to the English speaking minority insert here Hello world! in Chinese and Indic/. QT can do the same and is faster. I don't know why nore do I care, I am a java developer so these things do not really count for me - I am a user-only and quite bothered by slow GTK UIs. lg Clemens PS: Peace ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] btcond / d-bus problems[MESSAGE NOT SCANNED]
On Wed, 28 Dec 2005, Johan Hedberg wrote: On Wed, Dec 28, 2005, Andrew Ramsay wrote: Is there anything obviously wrong with that? Nothing obvious, except that you should be passing a pointer to the string (i.e. char **) when calling get_args (and when done with the returned string free it with dbus_free). However, that shouldn't cause the problem you're describing. Do you get the same result if you use dbus-send from the command line: dbus-send --system --type=method_call --print-reply \ --dest=com.nokia.btcond /com/nokia/btcond/request \ com.nokia.btcond.request.rfcomm_bind string:00:02:76:C0:56:A4 string:SPP Johan Running that gives me exactly the same error as the programmatic method. I'm about to try reflashing the N770 with the last software update file, in case something I've done to it is causing the problems. Andrew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Irrelevant comparisons (was Re: testing pango with 770)
Hi, Eero Tamminen kirjoitti 28.12.2005 kello 17.10: Hmm, yep it flickers but on the other side resizing windows or sub-windows is incredible slow with GTK2. I think this might be due to high amount of signaling, especially with deep widget hierarchies. I think it's mostly because of how gtk+ handles size allocations. By default, when a widget's size changes, all of it is redrawn. In other words, an expose-event covering whole of the widget's area is generated whenever there's a size-allocate event. And there's plenty of such events, when you slowly resize the toplevel window... There's a GTK_REDRAW_ON_ALLOC flag (defaulting to TRUE) in GtkWidget. Some stock widgets, such as GtkTreeView and GtkTextView unset the flag and take care of invalidating areas that need to be redrawn, and therefore resize more smoothly. But chances are there are many custom widget implementations that rely on the sub-optimal default behavior... I am not sure if that should be blamed on the toolkit, though. BR, Lassi ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
