Re: What should be used?
Hi Stefan, I am also in the process of converting my app from v2 to v3, where I do *lots* of drawing. So before jumping in, I decided to revisit a drawing example I posted some years ago to first convert it to v3 and its drawing to Cairo. In the hope of being useful for others, I have posted the converted code here: https://gitlab.com/ivor/GTK3-Cairo An overview of some of the concepts exampled: 1. Programmatically generated RGB buffers converted to cairo surface for display 2. Multiple background surfaces maintained over the lifetime of the program 3. Copying between Cairo surfaces 4. Drawing effects based on user input 5. Fade Transition effect between drawings using the alpha channel Enhancing this to demonstrate multi-threaded drawing should be a trivial task. cheers, richard On Wed, Jul 29, 2015 at 8:55 AM, Stefan Salewski m...@ssalewski.de wrote: On Wed, 2015-07-29 at 13:05 +0100, Emmanuele Bassi wrote: If you have legacy code that requires disabling double buffering, you should probably invest some time into porting it to a proper solution integrated with the GTK drawing model; It would be great if someone could port this example to GTK3: http://www.cairographics.org/threaded_animation_with_cairo/ Some months ago I was going to port that to Nim to test my GTK3 and Cairo bindings (https://github.com/StefanSalewski?tab=repositories) and to have one more example. But then I discovered that this one seems to be still GTK2, and has gtk_widget_set_double_buffered(window, FALSE); I may be able to get that C code to compile with GTK3, but unfortunately I may not be able to make it a really fine GTK3/Cairo example, so it would not make much sense to convert it to Nim then. Does someone know another fine small GTK3/Cairo example (C, C++, Ruby, Python -- or maybe arbitrary other language) which is not outdated? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: What should be used?
Emmanuel, I asked on the other thread but nobody replied :( What is the minimum GTK+ version for GtkLinkButton signnal activate-link. And how to stop propagating the click on it with GTK+2 where this is not available? Thank you. On Wed, Jul 29, 2015 at 10:12 AM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 29 July 2015 at 14:55, Stefan Salewski m...@ssalewski.de wrote: On Wed, 2015-07-29 at 13:05 +0100, Emmanuele Bassi wrote: If you have legacy code that requires disabling double buffering, you should probably invest some time into porting it to a proper solution integrated with the GTK drawing model; It would be great if someone could port this example to GTK3: http://www.cairographics.org/threaded_animation_with_cairo/ Those examples, especially the one that uses Unix signals to interrupt the program flow, ought to be burned with fire. Not only they are questionable in GTK 2.x, but they are also unportable jumbles of code that work by sheer accident. If you want to draw with Cairo on a separate thread Because Of Reasons™, then you need to create a Cairo surface using the GdkWindow API — see gdk_window_create_similar_image_surface() — then draw on it from within your thread; at the end of the thread, queue a redraw on the widget. At the same time, inside a GtkWidget::draw handler, use the Cairo surface you drew on inside the thread, set it as you source, and draw the surface on the Cairo context that GTK gives you. This way, the drawing code will happen in a separate thread, and you'll draw only when GTK tells you to draw. All considerations on accessing GTK and GDK API from the thread that called gtk_init/gtk_main (or g_application_run(), if you're writing modern code) still apply. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: What should be used?
On Wed, 2015-07-29 at 15:12 +0100, Emmanuele Bassi wrote: Those examples, especially the one that uses Unix signals to interrupt the program flow, ought to be burned with fire. Not only they are questionable in GTK 2.x, but they are also unportable jumbles of code that work by sheer accident. Thanks for your hints and explanations. The reason why I asked was, that I created a GTK3/Cairo application http://ssalewski.de/PetEd.html.en (which I just try to finish, currently in Ruby, maybe later ported to Nim) and so I was asked a few times about cairo drawing performance, and had some discussions about that topic. For my application performance is good enough, but threading support (or cairo-gl backed) is generally interesting -- so some more up to date examples would be great. I know that there is much better OpenGl support in GTK 3.16 now -- I am going to test that soon. But Cairo drawing has some benefits too, for example the various backends, which makes SVG or PDF export easy. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: What should be used?
Hi; On 29 July 2015 at 18:31, Igor Korot ikoro...@gmail.com wrote: Emmanuel, I asked on the other thread but nobody replied :( Don't hijack threads; it makes searching the archives impossible. What is the minimum GTK+ version for GtkLinkButton signnal activate-link. Since it's only available in GTK+ 3, and there's no Since annotation in the API reference, then it means it's available since the first release of GTK+ 3.0. And how to stop propagating the click on it with GTK+2 where this is not available? You can use the g_signal_stop_emission() function to stop the propagation of the GtkButton::clicked signal, except that the ::clicked signal is marked as RUN_FIRST, which means that the default handler inside the GtkButton (and any subclass overriding it) will be run first — and only then will your callback connected using g_signal_connect() be called. Which means you cannot prevent the default handler from running. Having said that, I must also warn you: do not try to support GTK+ 2 and GTK+ 3 in the same code base. It was doable back when GTK+ 3 was new, four years ago, but the code base, requirement, assumptions, and API have been diverging to the point of being a massive waste of time — for you, for packagers, for users, and for people answering your questions. Either stick with GTK+ 2.24, or port to GTK+ 3. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
What should be used?
Hi, ALL, The documentation says: [quote] gtk_widget_set_double_buffered has been deprecated since version 3.14 and should not be used in newly-written code. This function does not work under non-X11 backends or with non-native windows. It should not be used in newly written code. [/quote] However it does not say what should be used instead. Could somepone please clarify? Thank you. ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: What should be used?
Hi; On 29 July 2015 at 12:51, Igor Korot ikoro...@gmail.com wrote: Hi, ALL, The documentation says: [quote] gtk_widget_set_double_buffered has been deprecated since version 3.14 and should not be used in newly-written code. This function does not work under non-X11 backends or with non-native windows. It should not be used in newly written code. [/quote] However it does not say what should be used instead. Nothing should be used instead. All widgets inside GTK are double-buffered, and all windowing systems are double buffering the drawing surfaces used to present things on the screen. The only reason why somebody would remove double buffering is when dealing with native surfaces directly, for instance when using OpenGL on X11; this not only is generally broken, but also breaks the drawing internals of GTK unless you constrain your requirements. Since GTK+ 3.16, OpenGL is natively supported by GTK in a way that works with the internal drawing model, so it's not necessary to use any other external library or external code to use OpenGL — thus gtk_widget_set_double_buffered() should not be used. If you have legacy code that requires disabling double buffering, you should probably invest some time into porting it to a proper solution integrated with the GTK drawing model; in the meantime, you can still call set_double_buffered() in your code. The API and its behaviour won't go away until GTK+ 4.0. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: What should be used?
On Wed, 2015-07-29 at 13:05 +0100, Emmanuele Bassi wrote: If you have legacy code that requires disabling double buffering, you should probably invest some time into porting it to a proper solution integrated with the GTK drawing model; It would be great if someone could port this example to GTK3: http://www.cairographics.org/threaded_animation_with_cairo/ Some months ago I was going to port that to Nim to test my GTK3 and Cairo bindings (https://github.com/StefanSalewski?tab=repositories) and to have one more example. But then I discovered that this one seems to be still GTK2, and has gtk_widget_set_double_buffered(window, FALSE); I may be able to get that C code to compile with GTK3, but unfortunately I may not be able to make it a really fine GTK3/Cairo example, so it would not make much sense to convert it to Nim then. Does someone know another fine small GTK3/Cairo example (C, C++, Ruby, Python -- or maybe arbitrary other language) which is not outdated? ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: What should be used?
Hi; On 29 July 2015 at 14:55, Stefan Salewski m...@ssalewski.de wrote: On Wed, 2015-07-29 at 13:05 +0100, Emmanuele Bassi wrote: If you have legacy code that requires disabling double buffering, you should probably invest some time into porting it to a proper solution integrated with the GTK drawing model; It would be great if someone could port this example to GTK3: http://www.cairographics.org/threaded_animation_with_cairo/ Those examples, especially the one that uses Unix signals to interrupt the program flow, ought to be burned with fire. Not only they are questionable in GTK 2.x, but they are also unportable jumbles of code that work by sheer accident. If you want to draw with Cairo on a separate thread Because Of Reasons™, then you need to create a Cairo surface using the GdkWindow API — see gdk_window_create_similar_image_surface() — then draw on it from within your thread; at the end of the thread, queue a redraw on the widget. At the same time, inside a GtkWidget::draw handler, use the Cairo surface you drew on inside the thread, set it as you source, and draw the surface on the Cairo context that GTK gives you. This way, the drawing code will happen in a separate thread, and you'll draw only when GTK tells you to draw. All considerations on accessing GTK and GDK API from the thread that called gtk_init/gtk_main (or g_application_run(), if you're writing modern code) still apply. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
