Web lists-archives.com

Re: double_buffered and scrolled_window

Hi Emmanuele and thanks for the detailed reply. Boy, do I feel like I flunked the widget writing class. :-)

I'll take all your recommendations into consideration as time allows.

I realize that gob is dead. I should be going to pure C instead. I can't even use the straight gob output, but have to patch it before compiling....

You are correct that I copied the window creation code from the GdkDrawingArea widget. I'll correct it based on the CustomWidget tutorial.

Regarding GdkPixbuf, Indeed I'm composing the whole image before shipping it to the screen. I currently do this for two reasons. One is that I want to be able to do nearest neighbor scaling, instead of bilinear scaling, when zooming up images. But perhaps this is possible with cairo as well? The second reason is that I'm still using agg for drawing vector graphics instead of cairo. A few years back when I compared the speed, of the two I found agg to be much faster than cairo, but perhaps that has changed now?

Regarding, the gestures, is there a tutorial of how to use them? The CustomWidgets tutorial mentions them, but then goes on to describe the button and motion notify events.

Thanks again!

On Mon, Apr 16, 2018 at 12:41 PM, Emmanuele Bassi <ebassi@xxxxxxxxx> wrote:
On 16 April 2018 at 10:19, Dov Grobgeld <dov.grobgeld@xxxxxxxxx> wrote:
Hi all,

After lots of years I finally got around to porting my widget GtkImageViewer to gtk3. After doing lots of reading of man pages, did I realize that i can turn off double buffering.

I wonder what kind of man pages did you read, considering that the API reference of gtk_widget_set_double_buffered() clearly states that it's deprecated and doesn't do anything remotely useful:


You should *never* disable double buffering — and you should never need it. Double buffering is an intrinsic characteristic of the windowing system; if you disable it, it means you're literally owning the rendering pipeline — which is why it's still used by applications that render their own UI inside a GTK top level, like Firefox or LibreOffice. Given their user base, we try to avoid breaking their use cases, but we do not really recommend other people try doing that.

GTK widgets should always use the rendering pipeline provided by GTK, not work around it; we do not make any guarantees if you decide to eschew that.

I honestly couldn't read your code because it's using Gob — something that has long since been deprecated and it's not even remotely up to date with the GObject and GTK best practices. From what I could glean:

 - it seems you started from the GtkDrawingArea code, which has some backward-compatibility functionality, like a custom window and the need to send configure events; those are not needed in newly written code
 - you're not using the GTK 3.22 API; for instance, you should be calling gtk_widget_register_window() when creating a new GdkWindow inside the realize() function
 - you're still using GdkPixbuf to do scaling and compositing, instead of using Cairo
 - you're using a client input/output GdkWindow for rendering, instead of rendering directly on the parent's surface
 - you're using a background color and compositing it, instead of using the style system to render the background and border
 - you should be using the Gesture API, instead of connecting to each event in order to do zoom and scroll

There is a wiki page on how to write widgets: https://wiki.gnome.org/HowDoI/CustomWidgets



gtk-devel-list mailing list