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



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 <mortenw 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
<jstpierre 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 <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.
>>
>> Thanks!
>>
>> --
>>   Jasper
>
>
>
>
> --
>   Jasper
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



--
  Jasper


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]