[gtk+] Add more hints
- From: Matthias Clasen <matthiasc src gnome org>
- To: svn-commits-list gnome org
- Cc:
- Subject: [gtk+] Add more hints
- Date: Thu, 10 Sep 2009 17:55:10 +0000 (UTC)
commit d409cf2bf395896e856fe1affe438dd0c041824f
Author: Matthias Clasen <mclasen redhat com>
Date: Thu Sep 10 13:51:02 2009 -0400
Add more hints
Mention problems related to cairo and clipping.
.../reference/gtk/migrating-ClientSideWindows.sgml | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
---
diff --git a/docs/reference/gtk/migrating-ClientSideWindows.sgml b/docs/reference/gtk/migrating-ClientSideWindows.sgml
index 5eecd19..3860ee5 100644
--- a/docs/reference/gtk/migrating-ClientSideWindows.sgml
+++ b/docs/reference/gtk/migrating-ClientSideWindows.sgml
@@ -39,4 +39,17 @@
may be affected by this.
</para>
+ <para>
+ Problems can also occur when using cairo for drawing. One thing that can
+ go wrong is clip handling. If you ever need to reset the clip region on
+ a cairo_t (i.e. use cairo_reset_clip()), you have to to use
+ gdk_cairo_reset_clip() instead. The reason for this is that the cairo_reset_clip() call will remove the initial clip region that limits your drawing to
+ the client-side window at hand, so you will end up drawing over stuff
+ outside the window. You also need to use gdk_cairo_reset_clip() if you
+ use a cairo_t that was not allocated in a double-buffered expose handler
+ and keep it in use after window hierarchy changes (resizing, moving,
+ stacking order changes). The easiest fix for this kind of problem is to
+ simply create a new cairo context for each expose event.
+ </para>
+
</chapter>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]