Please review gtkglext-3
BUMP! Dear GTK developers, I work on a port of gtkglext (i.e., GTK's OpenGL library) to GTK 3. To push the changes upstream, I need someone to review the patches and give me feedback. The original reviewer suddenly disappeared, so I'm asking one of you to do the review. If you're interested, clone git://git.gnome.org/gtkglext and pull my changes from https://github.com/tdz/gtkglext.git for-review The content of these patches is described in [1], [2] and [3]. Thanks in advance and Best Regards Thomas [1] http://mail.gnome.org/archives/gtkglext-list/2012-January/msg6.html [2] http://mail.gnome.org/archives/gtkglext-list/2012-January/msg00020.html [3] http://mail.gnome.org/archives/gtkglext-list/2012-January/msg00021.html -- GnuPG: http://tdz.users.sourceforge.net/tdz.asc Fingerprint:16FF F599 82F8 E5AA 18C6 5220 D9DA D7D4 4EF1 DF08 jsapigen - A free glue-code generator for Mozilla SpiderMonkey. See http://jsapigen.sourceforge.net for more information. signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
hi, On Mon, 2012-03-05 at 14:58 +, Michael Meeks wrote: > Ryan: when you say "the main thread" - what does that mean ? does it > mean from "a single thread" - as in we need to guarentee that the calls > are only ever actually happening from a single thread at a time ? or > does it mean that you will get/check/assert/behave-differently if code > is executed if pthread_self() doesn't match[1] some magic, > pre-initialized variant ? To point at something concrete: attempting to use GTK on Windows from something other than the main thread will result in bad behaviour (even if you're holding the GDK lock) because Windows doesn't like you interacting with a window from a thread that is not the one that created it. > My question would be though - what is the benefit here ? See above. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
On Mon, Mar 5, 2012 at 9:34 AM, Andy Wingo wrote: > Heya, > > On Mon 05 Mar 2012 14:07, Ryan Lortie writes: > >> On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote: >>> Does that mean you're removing gdk_threads_enter and leave and the >>> semantics around that ? is there some cunning new scheme proposed to >>> intercept the mainloop and ensure that events / idle / timeout emissions >>> hooked in by the toolkit can have applications add lock/unlock pairs ? >> >> We're not removing -- only deprecating. >> >> The removal will come in GTK4. There will be no replacement >> functionality -- you will just be expected to do all your interaction >> with the toolkit from the main thread (ie: dispatching results via >> idles). > > You're sure this is a good idea? > > I really liked Java-GNOME's approach to the issue: > > http://blogs.operationaldynamics.com/andrew/software/java-gnome/thread-safety-for-java > > Would this mode of interaction with GTK+ not be supported in the future? well, lets think about this for a moment. you've got some worker thread that has done some work (probably computational, but possibly i/o based) and now as a result it wants to change the appearance of some part of a window owned by the process. there are 2 possible scenarios: 1) the main GTK thread is currently busy, and thus the worker thread would have to block anyway 2) the main GTK thread is blocked in its main event loop, and so the worked thread could potentially make GTK/GDK calls itself in the first case, i don't see what is gained by having the worker thread block rather than just schedule an idle callback. in the second case, it initially seems silly to schedule an idle callback when you could just make the relevant calls to GTK/GDK inline. but lets think a little bit about what those calls are going to do. ultimately, they are going to invoke gtk_widget_queue_draw() or its cousins. they are not not going to actually draw on the window, since that only happens during expose event handling. so in fact, the window redraw won't take place inline unless the worker thread also invokes an iteration of the gtk main loop. this is now (to me) starting to seem like a worse and worse idea. instead, just push all the GTK/GDK calls into a function that can be executed as an idle callback. call g_idle_add(). the main GTK thread wakes up, executes the code, hits the idle processing loop, synthesizes expose events, redraws the window. the downside is that every worker thread now requires at least one additional function to be invoked from an idle callback. compared to the upside: no locking protocol, and better enforcement of a model/view/controller design - this seems like a small price to pay. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
Heya, On Mon 05 Mar 2012 14:07, Ryan Lortie writes: > On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote: >> Does that mean you're removing gdk_threads_enter and leave and the >> semantics around that ? is there some cunning new scheme proposed to >> intercept the mainloop and ensure that events / idle / timeout emissions >> hooked in by the toolkit can have applications add lock/unlock pairs ? > > We're not removing -- only deprecating. > > The removal will come in GTK4. There will be no replacement > functionality -- you will just be expected to do all your interaction > with the toolkit from the main thread (ie: dispatching results via > idles). You're sure this is a good idea? I really liked Java-GNOME's approach to the issue: http://blogs.operationaldynamics.com/andrew/software/java-gnome/thread-safety-for-java Would this mode of interaction with GTK+ not be supported in the future? I think I missed the original mail :) Andy -- http://wingolog.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
hi; On 5 March 2012 13:07, Ryan Lortie wrote: > The removal will come in GTK4. There will be no replacement > functionality -- you will just be expected to do all your interaction > with the toolkit from the main thread (ie: dispatching results via > idles). AFAIR, the java-gnome bindings used the GDK threading markers to replace the mutex used internally by GDK with a recursive one, that suited the java programming model. also, Libre/OpenOffice chained up their Big Fat Lock™ to GDK's one. I guess we'll have to maintain the gdk_threads_set_lock_functions(), and internally use gdk_threads_enter()/_leave(), even if the API is not available in public headers. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
hi Michael, On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote: > Does that mean you're removing gdk_threads_enter and leave and the > semantics around that ? is there some cunning new scheme proposed to > intercept the mainloop and ensure that events / idle / timeout emissions > hooked in by the toolkit can have applications add lock/unlock pairs ? We're not removing -- only deprecating. The removal will come in GTK4. There will be no replacement functionality -- you will just be expected to do all your interaction with the toolkit from the main thread (ie: dispatching results via idles). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Signal emission changes
I just landed a bunch of signal emission optimizations in gobject. It should be transparent to everyone, although it you're using an non-standard signal marshaller for a heavily used signal you might want to look at setting a custom va_marshaller. The basic idea is that for a the (common) case of a single signal handler when various complex signal emission features are not in use we can avoid collecting the va_list from g_signal_emit_valist() into GValues and demarshall the va_list immediately into the callback arguments. This gives performance increases in the range 10-20 fps in the clutter performance checks, and could also help in e.g. the gtk+ size allocation machinery. I've added some new signal tests, and I'm running my entire session with this without any problems. However, its possible that there is some edge case that broke, so if you see weird behaviour wrt signal emissions try a glib without this change and report any problems to me. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: Problems with Glib 2.30.2 using the Blackfin processor
Hello everyone, First of all sorry if you receive 2 copies of this email (I thought I was registered to the mailing list, but I wasn't) My problem: I'm trying to use the Glib 2.30.2 in the blackfin processor, but I'm having some issues (the same example running in the x86 works fine): I'm using an example that can be downloaded using the following link: http://dl.dropbox.com/u/7795730/example.tar.gz The output of the example is: root:/tmp> ./example_test ** (process:310): DEBUG: dgt_example_init: [0x2dc4000] instance initialized (process:310): GLib-GObject-CRITICAL **: g_object_notify_queue_thaw: assertion `nqueue->freeze_count > 0' failed ** (process:310): DEBUG: dgt_example_init: [0x2dc4070] instance initialized ** (process:310): DEBUG: main: example1 (defined on constructor) mock[7] example2 (default value) mock[777] ** (process:310): DEBUG: main: example2 mock now is [144000] ** (process:310): DEBUG: main: lets connect on the signals ** (process:310): DEBUG: main: calling add method ** (process:310): DEBUG: dgt_example_add: emiting a signal to inform that i am about to perform a sum ** (process:310): DEBUG: example_callback: example[0x2dc4000] is going to sum a[5] + b[5] ** (process:310): DEBUG: example_callback: udata is [Example 1 Userdata] ** (process:310): DEBUG: dgt_example_do_sum: doing sum, a[5] + b[5] ** (process:310): DEBUG: dgt_example_add: result is [10] ** (process:310): DEBUG: main: res[10] ** (process:310): DEBUG: dgt_example_add: emiting a signal to inform that i am about to perform a sum ** (process:310): DEBUG: example_callback: example[0x2dc4070] is going to sum a[7] + b[13] ** (process:310): DEBUG: example_callback: udata is [Example 2 Userdata] ** (process:310): DEBUG: dgt_example_do_sum: doing sum, a[7] + b[13] ** (process:310): DEBUG: dgt_example_add: result is [20] ** (process:310): DEBUG: main: res[20] ** (process:310): DEBUG: main: unreffing examples SEGV I've debugged the problem and aparently in the object creation (g_object_newv) the queue it's freezed once and thawed twice (this sometimes happens in the initialization of the first object(like this output), and sometimes in the latter), and thus failing the assert, and later it gives a segfault when destroying the objects. My main question is: what can be the root of this problems? I believe no one tried to use this version of Glib in the Blackfin processor (because the libffi doesn't have a port for this processor(I made my own port of libffi)). Thanks for the attention, any help will be appreciated Alexandre Mendonça ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
