I am in the process of converting a graphics app from GTK 3.20 to 3.22. Most of the API changes are not hard to deal with, but there is one that is causing me severe design problems. I hope someone with a deeper understanding of GTK can suggest a path forward.
My application code writes extensively to GdkWindow objects using cairo and cairo with pixbufs. This is often done directly on the window, outside of draw events, usually in mouse events. I see now that this is not recommended, however I have done this up to now in hundreds of places without problems, and the performance is great. I cannot imagine showing lines being drawn or areas painted in real time if I must queue draw events and let them run for every tiny change. Maybe this is feasible and fast enough, but would require a total redesign and maybe months of work. What I am missing is cairo_t * gdk_cairo_create(GdkWindow *) which is deprecated and replaced with gdk_window_begin_draw_frame() and gdk_drawing_context_get_cairo_context(). In the past, using gdk_cairo_create(), I created a cairo context wherever in the code I needed, and destroyed it when done. There are times when a mouse event function is re-entered while still busy, because new mouse events happen during execution and sometimes functions are called that iterate the main loop. Creating and destroying parallel cairo contexts was not a problem up to now, apparently. This is no longer possible, because only one drawing context can be defined for a GdkWindow, and there is no way to find out if a GdkWindow already has one or not. You can go from a GdkDrawingContext to a matching GdkWindow, but not the other way around. Is there a way? Also, If a drawing context is created for a GdkWindow, what happens if there is a draw event and the window is repainted? I presume the created drawing context is now invalid, or GTK will fail when creating the automatic new drawing context for the draw event because another context already exists. It also seems that if the window is resized, the drawing context becomes invalid because the size of the drawing region is fixed by the call to gdk_window_begin_draw_frame(). Am I right to think that the new API has a performance advantage in that the backing store is only as large as the pre-declared drawing region? (presuming the extra code to calculate a minimum region before each set of window draws). I am hoping for a suggestion about how best to deal with this. Thanks in advance. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
