Sure, I'm not familiar with the Win32 or Quartz backends, so I didn't want to say anything too definitive about those backends. But it's nice to hear that it works as well.
On Mon, Jun 23, 2014 at 6:39 PM, Morten Welinder <mort...@gnome.org> wrote: > For the record, the use of gdk_cairo_create outside of a > begin_paint_region / end_paint pair also seems to work fine on win32. > > Morten > > > On Mon, Jun 23, 2014 at 6:02 PM, Jasper St. Pierre > <jstpie...@mecheye.net> wrote: > > Hey everyone again > > > > I wasn't expecting this much fallout from the change. I was hoping most > of > > the GTK+ applications were only using widgets and draw signals. I was > wrong. > > > > I've effectively pushed a revert of these changes: > > > > > https://git.gnome.org/browse/gtk+/commit/?id=984e811c16891cb4945a090bea8ec9e81ce3dba6 > > > https://git.gnome.org/browse/gtk+/commit/?id=24b9e91f470d2f355c6e19013f302295151baacf > > > > Note that gtk_widget_set_double_buffered is still deprecated, and calling > > gdk_cairo_create outside of a begin_paint_region / end_paint is still > > considered legacy and isn't guaranteed to work on any backends other than > > X11. Everything should be functioning correctly. So, we're choosing to > make > > these things work for X11, but new backends like Wayland, Broadway and > Mir > > might not work with them. > > > > If your application still has flickering or prints runtime warnings or > > crashes, *please* let me know. We should be back to where we were > > beforehand, but things do sometimes slip through the cracks. > > > > Thanks to everyone who gave me feedback -- it's been a frustrating past > few > > days for everyone, and I'm sorry for the breakage I caused. I have a much > > better handle on the situation now and the way applications are using our > > toolkit. > > > > If you have any other feedback about modern drawing in GTK+, please let > us > > know. We're always trying to support application developers, even if it > may > > not seem like it, and if our existing APIs aren't suiting your use > cases, we > > need to know. > > > > > > On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre < > jstpie...@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. > >> > >> Thanks! > >> > >> -- > >> Jasper > > > > > > > > > > -- > > Jasper > > > > _______________________________________________ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > -- Jasper
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
