[gtk] Add call to BeginPaintRect()/EndPaintRect() before and after Event... #268

wants to merge 1 commit into


None yet

4 participants

Mono Project member


This enables double buffering for user code.

@atsushieno atsushieno [gtk] Add call to BeginPaintRect()/EndPaintRect() before and after Ev…

This enables double buffering for user code.
Mono Project member

Aren't GTK widgets already double-buffered by default?

Mono Project member

It is documented so, but as long as I tried with my project[*1] it didn't.

[*1] https://github.com/atsushieno/xmdsp


Looking at gtk+-2.12.0, in gdkwindow.c, the comment to gdk_window_begin_paint says:-

  • When using GTK+, the widget system automatically places calls to gdk_window_begin_paint_region() and
  • gdk_window_end_paint() around emissions of the expose_event signal. That is, if you're writing an
  • expose event handler, you can assume that the exposed area in #GdkEventExpose has already been cleared
  • to the window background, is already set as the clip region, and already has a backing store.
  • Therefore in most cases, application code need not call gdk_window_begin_paint_region(). (You can disable the
  • automatic calls around expose events on a widget-by-widget basis by calling gtk_widget_set_double_buffered().)

This does seem to be the default behaviour, as far as I've experienced. How do you experience it not being the case?

Mono Project member

This BeginPaintRect() and EndPaintRect() https://github.com/atsushieno/xmdsp/blob/gtk-sharp/Xmdsp/View.Xwt/KeyboardList.cs#L90 fixed significant performance issue in my app mentioned above. It uses DrawingArea.

Mono Project member

I think this can be closed. If someone experiences the same problem, please open a new issue with some example Xwt based code, so it can be reproduced by others.

@sevoku sevoku closed this Jan 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment