I haven't programmed much with gtk+, so forgive a noob if this is a silly
question. My first impression when I looked at the architecture (using
GObject etc.) was that this must take quite a bit of processing cycles and
memory. So my question is: is there any room for improvement by rethinking
the
2008/12/22 Eugene Gorodinsky e.gorodin...@gmail.com:
question. My first impression when I looked at the architecture (using
GObject etc.) was that this must take quite a bit of processing cycles and
memory. So my question is: is there any room for improvement by rethinking
the architecture
On Mon, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote:
I haven't programmed much with gtk+, so forgive a noob if this is a
silly question. My first impression when I looked at the architecture
(using GObject etc.) was that this must take quite a bit of processing
cycles and memory. So my
Vala is a high level language which is translated to GObject and C, so
you are proposing to rewrite GObject using GObject.
Vala can be modified, since it is open source and all. I'm not sure if
that's feasible though, as I'm not familiar with it.
___
Am Montag, den 22.12.2008, 14:27 +0100 schrieb Olav Vitters:
On Mon, Dec 22, 2008 at 03:10:13PM +0200, Eugene Gorodinsky wrote:
Vala is a high level language which is translated to GObject and C, so
you are proposing to rewrite GObject using GObject.
Vala can be modified, since it is
On mån, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote:
I haven't programmed much with gtk+, so forgive a noob if this is a
silly question. My first impression when I looked at the architecture
(using GObject etc.) was that this must take quite a bit of processing
cycles and memory. So my
On Mon, 2008-12-22 at 15:22 +0100, Robin Sonefors wrote:
I think I got this impression of GObject because it forces you to really
see the overhead, when most other languages/libraries works harder to
hide more. For instance, the code generated for a virtual function in
C++ is as far as I
On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote:
the code generated for a virtual function in C++ is as far as I
understand (as I said, noob here) in principle the same as the
code you have to manually write in GObject to do the same thing,
it's just much more invisible.
Am Mon, 22 Dec 2008 16:44:55 +0100
schrieb Alberto Garcia agar...@igalia.com:
On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote:
the code generated for a virtual function in C++ is as far as I
understand (as I said, noob here) in principle the same as the
code you have to
Hi,
On Mon, 2008-12-22 at 16:44 +0100, Alberto Garcia wrote:
However, there is a performance problem with private attributes
(if you use g_type_class_add_private()) that don't exist in other
languages, as GObject's g_type_instance_get_private() can be
noticeably slow.
That can easily be
On Mon, Dec 22, 2008 at 07:54:59PM +0100, Sven Neumann wrote:
However, there is a performance problem with private attributes
(if you use g_type_class_add_private()) that don't exist in other
languages, as GObject's g_type_instance_get_private() can be
noticeably slow.
That can easily
On Mon, Dec 22, 2008 at 05:30:32PM +0100, Christian Dywan wrote:
As you say, because type casts are dinamic, there's the overhead
of calling g_type_check_instance_* which in languages like C++ is
not needed because it's done at compilation time. I suspect that
this overhead is negligible
12 matches
Mail list logo
