On Mon, Jun 11, 2012 at 6:43 PM, Enrico Weigelt <weigelt@xxxxxxxx> wrote: > * Gour <gour@xxxxxxxxxxxx> wrote: > >> Found it...it talks about gtk3 2x slower than gtk2 which I really did >> not notice and cannot say how good that benchmark is to reflect real >> speed. > > Well, AFAIK, gtk had become much more dynamic than its older versions. > Maybe that's the problem: too many dynamic (heap) allocations, > lookups, etc, etc. Are you sure that's the cause of a slowdown? Did you make observations and measure data? > hmm, what could we possibly do about it ? > > Perhaps support efficient static allocations (.data segment), combined > with a DSL (and an, maybe even platform/target specific compiler) for > expressing the UI structures - something like Glade's XML files, but > meant for compiling instead of dynamic loading. > > Just some examples. > > Menus: (picked the example from the gtk tutorial (*1)) > > <menu id="main_menu" static="true" readonly="true"> > <submenu title="/_File"> > <item title="/_File/_New" hotkey="<control>N" handler="print_hello" /> > <item title="/File/_Open" hotkey="<control>O" handler="print_hello" /> > <item title="/File/_Save" hotkey="<control>S" handler="print_hello" id="save" readonly="false"/> > <item title="/File/Save _As" id="main_menu_save_as" readonly="false"/> > <separator /> > <item title="/File/Quit" hotkey="<control>Q" handler="gtk_main_quit" /> > </submenu> > <submenu title="/_Options" /> > <item title="/Options/Test" /> > </submenu> > <submenu title="/_Help" align="right"> > <item title="/_Help/About" /> > </submenu> > </menu> > > This notation has some interesting aspects: > > * the id attribute of the menu tells the menu compiler how the menu variable > (or macro) should be named. the compiler might also create several helper > inline functions macros or macros for operating on that menu (at least > for initialization and destruction) > * the entries for save and save-as also have id's, which just means they should > be accessible from the code as variables (or macros) and provide helper > macros/functions > * the static=true tells the menu compiler to generate some static struct (in .data) > * the menu's id will be used for the generated variable name > * the readonly=true tells it that the we never want to change anything here, > so it can decide to put that even into .cdata > * the item title's are just the gettext keys for the visual text, *not* the > path as used in GtkItemFactoryItem (the hierachy information is already > encoded in the XML structure) > * the hotkeys could be even translated into some (perhaps even platform > specific) input event code (so we dont need any mapping at runtime) > * handler functions are expected to be already (prototype-) defined > > In the end, the compiler will generate some .h and .c file holding all the code > for that menu and it's items. > > Our application might now initialize the menu (if there's some initialization > needed at all) by calling GTK_MENU_main_menu_init(). It can enable/disable the > save entry via GTK_MENU_ITEM_main_menu_save_enable(b). (<- b is a boolean flag). > > > By this approach we could also describe all the individual widgets, > windows, etc, by our own DSL and let the compiler handle the actual > code generation. Initial versions would just translate to the current > object types (hmm, shall we call that "classes" ? ;-o), later versions > would use specialized ones, where it also can directly generate > internal structures. > > This approach, IMHO, has several advantages: > > a) we can do more RAD (maybe not that far as with Glade's dynamic > loading) and make the whole application code easier to read/write > b) do performance/size optimizations behind the scenes, without > having to touch individual applications (once they're ported to > that new approach, of course ;-)). > > > Maybe we shoud review a bunch of smaller and larger gtk applications > and destill out some requirements catalog for that. > > > What do you think about that idea ? > > > cu > > [1] http://www.gtk.org/tutorial1.2/gtk_tut-13.html > -- > ---------------------------------------------------------------------- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > phone: +49 36207 519931 email: weigelt@xxxxxxxx > mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 > ---------------------------------------------------------------------- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > ---------------------------------------------------------------------- > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list -- Jasper _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
