* 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.
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
