Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

["A. Walton" <awalton gnome org>]

On Fri, Jun 20, 2014 at 9:01 PM, Jasper St. Pierre <jstpierre mecheye net> wrote:

On Fri, Jun 20, 2014 at 11:57 PM, A. Walton <awalton gnome org> wrote:

On Fri, Jun 20, 2014 at 6:00 PM, Jasper St. Pierre <jstpierre mecheye net> wrote:

To better support Wayland with fewer copies and less drawing artifacts, I've pushed some potentially breaking changes to GDK, namely around gdk_cairo_create and gdk_window_begin_paint_region.

https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

With these changes, it is now illegal to call gdk_cairo_create outside of a begin_paint / end_paint. This was always sketchy, and would never work on Wayland anyway. If your code does this, we will print a warning and return a dummy surface which won't ever be composited back into the main surface.

Additionally, it is now forbidden to call gdk_window_begin_paint_region more than once. Previously, the code had a "paint stack" which tracked paints, but since GTK+ never used this codepath it was never actually tested and was indeed broken on Wayland due to the way the Wayland backend was written. Again, we will print a warning in this case and return.

As part of these changes, gtk_widget_set_double_buffered was deprecated and removed. Again, it will never work on Wayland, as that is natively double-buffered, and it would simply break there.

I tested with some local big applications like Ardour and the GNOME applications, but don't have a GTK+3 build of Firefox, LibreOffice, Eclipse, or any big GTK+ apps like Inkscape or The GIMP.

Please double-check to make sure your apps still work fine. If you have a problem with any of this or I broke your apps by accident, please reply and I'll try to fix it.

While I don't have anything negative to say about this particular patch series (I honestly think it's somewhat overdue), encoding knowledge such as this into commits and mailing list messages make it much, much harder to develop applications against Gtk+.

None of the commits that changed this did anything to touch the documentation saying why this was the case and how to fix your applications if they're busted. "This is not allowed" should be "This is not allowed since [when]". The commit that removed the double buffering property should emit a warning if an application sets the flag to false so that application developers can catch this kind of thing in development.

We haven't ever emitted runtime warnings for using deprecated APIs, and I'm not sure I want to start doing that for now. Are the compile-time deprecation warnings not enough for you?

I'm not aware of how applications might be broken by the gtk_widget_set_double_buffered deprecation, and the other cases had runtime warnings attached to them.

[Commercial Developer Hat - speaking on behalf of myself and not the company]

My day job is maintaining an application called VMware Workstation. The application is among one of the oldest and largest Gtk+ codebases at 15 years old, and has survived almost every major GNOME regime change from Gtk+ 1.3 to Bonobo to the D-Bus revolution to GIO to Gtk+ 3. As you might imagine, we're stuck using a few deprecated APIs (like, e.g., stock icons, of which we get thousands of warnings for alone while compiling).

As such, we hit all kinds of these random issues through the ages, where subtle changes are made in Gtk+ and we spend our time tracking them down through Google and grepping hopefully through git logs. It's tiresome and it is rapidly turning my beard gray.

The runtime warning would be incredibly helpful for tracking down these kinds of things in development - we build shipped versions of our application with these warnings suppressed anyways, and the GNOME team has already done(/undone ;) this in many other occasions:

https://git.gnome.org/browse/glib/commit/?id=85e9455f68c6cc6093a1ede1c5f15587bba08b51
https://git.gnome.org/browse/glib/commit/?id=f2f66bfe45f41d18e7437341e5ebf4c70d815958

-Andrew Walton

 

I beg of you guys as both a commercial and open source GTK+ application developer, show us a tiny bit of mercy and document changes like this in places other than commit messages and mailing list threads.

 

Any suggestions for where else to document them? I marked all the appropriate functions as deprecated and changed their documentation to say that they do nothing. I'd be happy to adjust the documentation, but I'm not aware of anywhere else I can do it.

Thanks for your work Jasper,

-Andrew Walton

 

Thanks!

--
  Jasper

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

--
  Jasper