Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Le samedi 21 juin 2014 à 11:28 -0400, Jasper St. Pierre a écrit : > On Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre > wrote: > Honest question: which ones? The only requirement we have with > Wayland is that we know when a paint has begun and when it has > ended, and also the rough area of paint, so we can tell the > Wayland compositor when to swap buffers, and from which > rectangles. > > > The draw signal does this automatically, but we can expose > this in other places. > > I'm skeptical of the performance concerns of the draw signal. > With the new paint clock system we have, draw events are > throttled and locked to the compositor, so it should be faster > to queue a redraw and wait until the frame is drawn, and do it > all in one go. But I'm fine with changing begin_paint_region > so that it no longer clears to background, if only to help > people trying to port to the crazy new drawing world. > > > > Heads-up: I went ahead and pushed a branch for this at > https://git.gnome.org/browse/gtk+/log/?h=wip/paint-stack-cleanup > > > Basically, gdk_window_begin_paint_region / gdk_window_begin_paint_rect > no longer clear to the background automatically, which means you can > use them out-of-band. To clear to the background explicitly, you can > use gdk_window_paint_background. > > > Since it adds new API, I'm not going to push it to master until I can > get some peer review, which likely means it won't get pushed until > Monday. If you could test with this branch and let me know the > results, that would be great! > > > I do encourage everyone to try using the "draw" event / "draw" signal > again. With our recent paint clock and event throttling work from 3.8 > onwards, we should be able to make it fast without having to resort to > hacks like gdk_cairo_create. > > > > Sorry for all the breakage! I really don't want to bug anybody too > much, but I do want to make sure that our toolkit and all our > applications can work out of the box on modern platforms like Wayland. We still had the issue with gtk+-3.8.6 (it's by that time that we started using gdk_create_cairo). Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 11:42 AM, Paul Davis wrote: > > the expose region or the expose "area" ? the former is a potentially > discontiguous set of rectangles, the latter is their union. yes? > > The expose region. See gtk_widget_send_expose: https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c#n7518 -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 11:21 AM, Jasper St. Pierre wrote: > On Sat, Jun 21, 2014 at 11:18 AM, Jean Brefort < > jean.bref...@normalesup.org> wrote: > >> I know that an expose event contains a region, but this does not help, >> we use the draw event, and I don't know how to reliably access the >> region. More, it is not really easy to determine what needs to be >> redrawn from inside a draw event. >> > > The cairo context you get in the draw signal is clipped to the expose > region > the expose region or the expose "area" ? the former is a potentially discontiguous set of rectangles, the latter is their union. yes? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 10:26 AM, Jasper St. Pierre wrote: > Honest question: which ones? The only requirement we have with Wayland is > that we know when a paint has begun and when it has ended, and also the > rough area of paint, so we can tell the Wayland compositor when to swap > buffers, and from which rectangles. > > The draw signal does this automatically, but we can expose this in other > places. > > I'm skeptical of the performance concerns of the draw signal. With the new > paint clock system we have, draw events are throttled and locked to the > compositor, so it should be faster to queue a redraw and wait until the > frame is drawn, and do it all in one go. But I'm fine with changing > begin_paint_region so that it no longer clears to background, if only to > help people trying to port to the crazy new drawing world. > Heads-up: I went ahead and pushed a branch for this at https://git.gnome.org/browse/gtk+/log/?h=wip/paint-stack-cleanup Basically, gdk_window_begin_paint_region / gdk_window_begin_paint_rect no longer clear to the background automatically, which means you can use them out-of-band. To clear to the background explicitly, you can use gdk_window_paint_background. Since it adds new API, I'm not going to push it to master until I can get some peer review, which likely means it won't get pushed until Monday. If you could test with this branch and let me know the results, that would be great! I do encourage everyone to try using the "draw" event / "draw" signal again. With our recent paint clock and event throttling work from 3.8 onwards, we should be able to make it fast without having to resort to hacks like gdk_cairo_create. Sorry for all the breakage! I really don't want to bug anybody too much, but I do want to make sure that our toolkit and all our applications can work out of the box on modern platforms like Wayland. -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 11:18 AM, Jean Brefort wrote: > I know that an expose event contains a region, but this does not help, > we use the draw event, and I don't know how to reliably access the > region. More, it is not really easy to determine what needs to be > redrawn from inside a draw event. > The cairo context you get in the draw signal is clipped to the expose region by default, which means that cairo will do culling for you automatically. If you need to do extra processing to determine if some complex update method should be run based on the clip region (which is really a big edge case -- you shouldn't need to do this!), you can use cairo_in_clip or cairo_clip_extents. -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Le samedi 21 juin 2014 à 11:05 -0400, Paul Davis a écrit : > > > > On Sat, Jun 21, 2014 at 10:35 AM, Jean Brefort > wrote: > In gnumeric this arised when we draw an animated rectangle > around the > selected rectangle. When using the draw event, we need to > repaint > everything inside the rectangle and this made gnumeric quite > unresponsive when there were many cells displayed at once. > > > i don't believe that this is true, but thanks for the explanation. > > > A draw/expose event contains a list of rectangles which need not be > contiguous. It is only a matter of convenience to use the GdkRectangle > that is also supplied. You can invalidate the "border" around the > cell. We do this in ardour, especially in our new canvas, where we > frequently queue discontiguous areas of the screen for drawing - when > we render we do not draw the union of all these areas, just each > rectangle in the list of regions. > I know that an expose event contains a region, but this does not help, we use the draw event, and I don't know how to reliably access the region. More, it is not really easy to determine what needs to be redrawn from inside a draw event. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 10:35 AM, Jean Brefort wrote: > In gnumeric this arised when we draw an animated rectangle around the > selected rectangle. When using the draw event, we need to repaint > everything inside the rectangle and this made gnumeric quite > unresponsive when there were many cells displayed at once. > i don't believe that this is true, but thanks for the explanation. A draw/expose event contains a list of rectangles which need not be contiguous. It is only a matter of convenience to use the GdkRectangle that is also supplied. You can invalidate the "border" around the cell. We do this in ardour, especially in our new canvas, where we frequently queue discontiguous areas of the screen for drawing - when we render we do not draw the union of all these areas, just each rectangle in the list of regions. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Le samedi 21 juin 2014 à 10:05 -0400, Paul Davis a écrit : > > > > On Sat, Jun 21, 2014 at 10:02 AM, Jean Brefort > wrote: > > > you're drawing on the window outside of an expose/draw > event?> > > > Yes, because using draw events presents serious performance > issues. > > can you describe these or point to a description of them? there are > several "native" window(ing) systems where this is actually impossible > to do. In gnumeric this arised when we draw an animated rectangle around the selected rectangle. When using the draw event, we need to repaint everything inside the rectangle and this made gnumeric quite unresponsive when there were many cells displayed at once. Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Honest question: which ones? The only requirement we have with Wayland is that we know when a paint has begun and when it has ended, and also the rough area of paint, so we can tell the Wayland compositor when to swap buffers, and from which rectangles. The draw signal does this automatically, but we can expose this in other places. I'm skeptical of the performance concerns of the draw signal. With the new paint clock system we have, draw events are throttled and locked to the compositor, so it should be faster to queue a redraw and wait until the frame is drawn, and do it all in one go. But I'm fine with changing begin_paint_region so that it no longer clears to background, if only to help people trying to port to the crazy new drawing world. On Sat, Jun 21, 2014 at 10:05 AM, Paul Davis wrote: > > > > On Sat, Jun 21, 2014 at 10:02 AM, Jean Brefort < > jean.bref...@normalesup.org> wrote: > >> >> > you're drawing on the window outside of an expose/draw event?> >> >> Yes, because using draw events presents serious performance issues. >> > > can you describe these or point to a description of them? there are > several "native" window(ing) systems where this is actually impossible to > do. > -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 10:02 AM, Jean Brefort wrote: > > > you're drawing on the window outside of an expose/draw event?> > > Yes, because using draw events presents serious performance issues. > can you describe these or point to a description of them? there are several "native" window(ing) systems where this is actually impossible to do. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Le samedi 21 juin 2014 à 09:55 -0400, Paul Davis a écrit : > > > > On Sat, Jun 21, 2014 at 9:44 AM, Jean Brefort > wrote: > Both abiword and gnumeric do something like: > > cr = gdk_cairo_create(win); > ...do some drawing > then relase the cairo. > > Will this still work if we use > > gdk_window_begin_paint_rect (win, rect); > cr = gdk_cairo_create (win); > ...do some drawing > gdk_window_end_paint (win); > > > you're drawing on the window outside of an expose/draw event? > Yes, because using draw events presents serious performance issues. Jean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Le 21/06/2014 03:00, Jasper St. Pierre a écrit : > 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. [...] > > 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. For the record, this makes Scintilla (http://www.scintilla.org/) emit tons of warnings. However, it seems relatively easy to fix and don't seem to actually break it, the triggering call being only due to the same code path being used in drawing and non-drawing contexts. So, fixing this would add complexity to the application code, but would avoid creating some unused contexts. All in all, it is a bit annoying to have to fix stuff again and again (the 3.9 drawing model change broke it also, because Scintilla has a somewhat bizarre toolkit usage as it has platform layers), but it should be fairly easy this time. Regards, Colomban ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Sure that it would help us if the the background was not cleared (I now remember that we avoided using them because of this feature). Thanks, Jean Le samedi 21 juin 2014 à 09:56 -0400, Jasper St. Pierre a écrit : > Yes, that should work. Make sure to test it, though, as > begin_paint_rect / begin_paint_region currently clears the specified > rect/region to the background set on the GdkWindow. If passing a more > exact region is too much of an annoyance, I should be able to also > change this without breaking too much so that the clear to background > only happens on expose events. > > > > It's difficult to balance the requirements of everybody. > > > > On Sat, Jun 21, 2014 at 9:44 AM, Jean Brefort > wrote: > Both abiword and gnumeric do something like: > > cr = gdk_cairo_create(win); > ...do some drawing > then relase the cairo. > > Will this still work if we use > > gdk_window_begin_paint_rect (win, rect); > cr = gdk_cairo_create (win); > ...do some drawing > gdk_window_end_paint (win); > > ? > > > > Le samedi 21 juin 2014 à 09:33 -0400, Jasper St. Pierre a > écrit : > > Can you two explain exactly what Abiword and Gnumeric are > doing, what > > APIs they're using and why and so on? We're trying to come > up with a > > solution that will work well under both X11 and Wayland. > > > > As I said, if it's a really bad break and would require > intensive > > changes to apps, I'll revert the patches. This is exactly > why I sent > > out the mail. > > > > > > On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort > > wrote: > > This will break abiword as well. > > > > Jean > > > > Le samedi 21 juin 2014 à 08:02 -0400, Morten > Welinder a > > écrit : > > > Argh! > > > > > > Will the stream of ABI changes never end? > > > > > > Gnumeric uses this to provide a walking-ant cursor > large > > selected areas -- areas > > > too big for processing in the normal paint loop. > > > > > > Morten > > > > > > -- > > Jasper > > > > > > > > > -- > Jasper > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Yes, that should work. Make sure to test it, though, as begin_paint_rect / begin_paint_region currently clears the specified rect/region to the background set on the GdkWindow. If passing a more exact region is too much of an annoyance, I should be able to also change this without breaking too much so that the clear to background only happens on expose events. It's difficult to balance the requirements of everybody. On Sat, Jun 21, 2014 at 9:44 AM, Jean Brefort wrote: > Both abiword and gnumeric do something like: > > cr = gdk_cairo_create(win); > ...do some drawing > then relase the cairo. > > Will this still work if we use > > gdk_window_begin_paint_rect (win, rect); > cr = gdk_cairo_create (win); > ...do some drawing > gdk_window_end_paint (win); > > ? > > > > Le samedi 21 juin 2014 à 09:33 -0400, Jasper St. Pierre a écrit : > > Can you two explain exactly what Abiword and Gnumeric are doing, what > > APIs they're using and why and so on? We're trying to come up with a > > solution that will work well under both X11 and Wayland. > > > > As I said, if it's a really bad break and would require intensive > > changes to apps, I'll revert the patches. This is exactly why I sent > > out the mail. > > > > > > On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort > > wrote: > > This will break abiword as well. > > > > Jean > > > > Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a > > écrit : > > > Argh! > > > > > > Will the stream of ABI changes never end? > > > > > > Gnumeric uses this to provide a walking-ant cursor large > > selected areas -- areas > > > too big for processing in the normal paint loop. > > > > > > Morten > > > > > > -- > > Jasper > > > > > -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Sat, Jun 21, 2014 at 9:44 AM, Jean Brefort wrote: > Both abiword and gnumeric do something like: > > cr = gdk_cairo_create(win); > ...do some drawing > then relase the cairo. > > Will this still work if we use > > gdk_window_begin_paint_rect (win, rect); > cr = gdk_cairo_create (win); > ...do some drawing > gdk_window_end_paint (win); > you're drawing on the window outside of an expose/draw event? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Both abiword and gnumeric do something like: cr = gdk_cairo_create(win); ...do some drawing then relase the cairo. Will this still work if we use gdk_window_begin_paint_rect (win, rect); cr = gdk_cairo_create (win); ...do some drawing gdk_window_end_paint (win); ? Le samedi 21 juin 2014 à 09:33 -0400, Jasper St. Pierre a écrit : > Can you two explain exactly what Abiword and Gnumeric are doing, what > APIs they're using and why and so on? We're trying to come up with a > solution that will work well under both X11 and Wayland. > > As I said, if it's a really bad break and would require intensive > changes to apps, I'll revert the patches. This is exactly why I sent > out the mail. > > > On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort > wrote: > This will break abiword as well. > > Jean > > Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a > écrit : > > Argh! > > > > Will the stream of ABI changes never end? > > > > Gnumeric uses this to provide a walking-ant cursor large > selected areas -- areas > > too big for processing in the normal paint loop. > > > > Morten > > > -- > Jasper > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Can you two explain exactly what Abiword and Gnumeric are doing, what APIs they're using and why and so on? We're trying to come up with a solution that will work well under both X11 and Wayland. As I said, if it's a really bad break and would require intensive changes to apps, I'll revert the patches. This is exactly why I sent out the mail. On Sat, Jun 21, 2014 at 9:18 AM, Jean Brefort wrote: > This will break abiword as well. > > Jean > > Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a écrit : > > Argh! > > > > Will the stream of ABI changes never end? > > > > Gnumeric uses this to provide a walking-ant cursor large selected areas > -- areas > > too big for processing in the normal paint loop. > > > > Morten > -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
This will break abiword as well. Jean Le samedi 21 juin 2014 à 08:02 -0400, Morten Welinder a écrit : > Argh! > > Will the stream of ABI changes never end? > > Gnumeric uses this to provide a walking-ant cursor large selected areas -- > areas > too big for processing in the normal paint loop. > > Morten > > > > > > On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre > 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 > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Argh! Will the stream of ABI changes never end? Gnumeric uses this to provide a walking-ant cursor large selected areas -- areas too big for processing in the normal paint loop. Morten On Fri, Jun 20, 2014 at 9:00 PM, Jasper St. Pierre 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 > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
