API changes, GTK 3.21 to 3.22, need advice to replace lost capability

[kornelix posteo de]

 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.