GNOME Bugzilla – Bug 624255
Remove internal use of gdk_draw_* API, deprecate
Last modified: 2011-02-04 16:12:18 UTC
Tracking the process of removing all internal uses of the gdk_draw_* and GdkGC API and marking the corresponding symbols deprecated. The work is being done on the rendering-cleanup branch in the gtk+ repo.
Just pushed a new update. Gone so far are: - GdkRGB - GdkImage - gdk_draw_{image,pixbuf} diffstat total: 89 files changed, 469 insertions(+), 12712 deletions(-) diffstat in gtk/ only: 10 files changed, 100 insertions(+), 418 deletions(-) And those are mainly redoing GtkColorButton and dropping the image property from GtkImage. There is a HUGE amount of cruft in Gdk.
A quick estimation of the work required to update applications can be found at http://people.gnome.org/~fpeters/reports/gdkdraw.html http://people.gnome.org/~fpeters/reports/gdkimage.html http://people.gnome.org/~fpeters/reports/gdkgc.html Ignore the complexity metrics. Hovering over the values gives the functions that are actually used.
So, I've finished the stuff I intended to do. Summary can be found athttp://mail.gnome.org/archives/gtk-devel-list/2010-July/msg00036.html Final diffstat: 146 files changed, 2730 insertions(+), 29384 deletions(-) As announced in the mail linked above, I'm now going to start merging into master. ;) (Actually, just the cleanup fixes, but I like that sentence.) Anybody up for a review so I can merge the other stuff, too?
There appear to be a couple of issues with the offscreen rendering code in the rendering-cleanup branch: 1. tests/testoffscreen crashes (tested on X11) because it runs out of stack. Infinite recursion happens through the following path: A scroll is initiated, this will queue an outstanding move at some point. For the offscreen case, gdk_window_flush_outstanding_moves() will call gdk_offscreen_window_translate(). gdk_offscreen_window_translate() calls gdk_cairo_create(). gdk_cairo_create() calls gdk_window_ref_cairo_surface(), which calls gdk_window_flush(). gdk_window_flush() will call gdk_window_flush_outstanding_moves(). 2. Damage events are not correctly created (ok, they are not created at all) for GdkOffscreenWindow. Where before add_damage() was called with the appropriate arguments from the implementation of gdk_draw_() functions in gdkoffscreenwindow.c, this does now no longer happen. The lacking damage events affect testoffscreen, as well as the offscreen demos in gtk3-demo.
2) is bug 621571 becoming more visible. In particular, double buffering doesn't call gdk_draw_drawable() anymore but uses cairo. Luckily that bug contains a patch.
(In reply to comment #5) > 2) is bug 621571 becoming more visible. In particular, double buffering doesn't > call gdk_draw_drawable() anymore but uses cairo. Luckily that bug contains a > patch. Ah, thanks. Mitch was talking to me about that patch last week, but didn't tell me where it was located :)
Both issues seem to have been resolved on X11 as Mattias has committed the patch in bug 621571 and Benjamin fixed the infinite recursion. Will try to finish up my patches for offscreen windows support on Mac soon now.
Update: gtk-2-22 branch has the deprecations landed. And the rendering-cleanup branch has no known bugs anymore, so it should be ready to land. See http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00053.html for an announcement of this to the wider world.
As the maintainer of Dia (complexity to port: "average") and one of the maintainers of the gdk/win32 drawing code I'm not very happy with your change. (I was coming to Dia to have a non-trivial user of the gdk_draw_*() set of functions. On Thu, Jul 22, 2010 at 4:54 AM, Benjamin Otte <otte@gnome.org> wrote: > [...] > So what do I intend to do next? > 1) Port some applications - the bigger users - to not use these > functions anymore. That way I'll both review my branch and get some > apps fixed. > I'd be very interested to review a patch for Dia, especially for your replacement of gdk_gc_set_function(tool->gc, GDK_XOR); AFAIK there is still no (and never will be) a straight replacement for that in cairo.
(In reply to comment #9) > As the maintainer of Dia (complexity to port: "average") and one of the > maintainers of the gdk/win32 drawing code I'm not very happy with your > change. (I was coming to Dia to have a non-trivial user of the gdk_draw_*() set > of functions. > You are not happy because of the work involved in porting your application or for other reasons? > I'd be very interested to review a patch for Dia, especially for your > replacement of gdk_gc_set_function(tool->gc, GDK_XOR); > AFAIK there is still no (and never will be) a straight replacement for that in > cairo. > CAIRO_OPERATOR_DIFFERENCE might work, if you are using a white source. For any source, nope, no such operator exists. I also don't think anyone would want such an operator, unless he'd want to appear retro. XOR and Stippling look very 80s.
(In reply to comment #10) > You are not happy because of the work involved in porting your application or > for other reasons? > Three resons: - wistfulness: throwing away quite well debugged code (not only that I have written) lowers the level of Gtk+ support for win32 - wasteoftime: putting effort to reimplment stuff decreases the time available to implement new Dia features - wrong reasons: IMO the most complex part in gdk/win32 is the emulation of the X11 event model. Ripping out the drawing code to reduce complexity is just not justified > CAIRO_OPERATOR_DIFFERENCE might work, if you are using a white source. IIRC GDK_XOR is used for the rubber-band selection of objects on canvas, so no there is no white source. > For any source, nope, no such operator exists. I also don't think anyone > would want such an operator, unless he'd want to appear retro. > XOR and Stippling look very 80s. That's the reason I'm interested in your approach to replace that functionality in Dia ;) Just repeating the arguments the cairo people had from the beginning of (cairo) time does not solve the immediate problem.
(In reply to comment #11) > > CAIRO_OPERATOR_DIFFERENCE might work, if you are using a white source. > IIRC GDK_XOR is used for the rubber-band selection of objects on canvas, > so no there is no white source. > I just checked, you're using it in the modify tool and in magnify.c. In both cases, you're using a white source (or foreground color as GdkGC calls it). So my suggestion of CAIRO_OPERATOR_DIFFERENCE with a white source should work.
The branch has been merged to master and the functions deprecated in Gtk 2.22. So even though I'll continue removing code, I guess we can close this bug?