Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
On Mon, Jun 23, 2014 at 10:20 PM, Krzysztof Kosiński wrote: > > On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis > > wrote: > > as Jasper noted in his reply, but i'll describe differently: it is one > thing > > to draw (even in a separate thread) in a cairo surface that can later to > > used during an actual redraw. and certainly many programs have excellent > > reasons to do this to speed up redrawing. but this doesn't involving > cairo > > drawing operations on the surface derived from a GdkWindow. you are > drawing > > to an image surface that is basically just memory inside your process. > you > > can do this from any thread, at any time. > > I am aware of this difference, and Inkscape already renders to > intermediate memory surfaces rather than directly to the window in the > idle callback, but due to some legacy code it also draws the finished > surface to the window in the idle callback. What currently happens is: > > - draw signal received > - queue exposed areas for rendering > - render in idle handler > - draw to window in idle handler > > and, as far as I understand, what needs to happen is: > > - draw signal received > - queue exposed areas for rendering > - render in separate thread > - invalidate part of the window corresponding to the completed rendering > - draw result to window in the draw signal handler > No, this is somewhat confused ... 1) Some *other* event/signal (user input, data ready, whatever) changes the state inside the application such that a redraw is required. 2) The application queues a redraw for the required areas (possibly the entire window, possibly various areas within it) 3) when the draw signal is finally received, draw something onto the surface derived from the window Now, the question is precisely what gets drawn in step (3). If the app is using an image surface "cache", then this cache will need to be rendered. It could be rendered within the draw signal handler, and then kept around for the next draw as well, or it could have been rendered before the draw signal is received (in an idle callback or in another thread) So what I think probably would happen in sodipodi is: * user input or data ready requires redraw * idle callback or another thread renders new image to an image surface * idle callback or a very carefully constructed call from another thread queues a redraw (invalidates part of the GdkWindow) * draw signal received * image surface used to render As a counterpoint, this is what happens in Ardour: * user input or data ready requires redraw * queue a redraw (invalidates part of the GdkWindow) * draw signal received (technically expose, since we're stuck in GTK+-2.x) * check for current cached image failure ? re-render cached image surface * render image surface to window surface we never use an idle callback or another thread for any graphics rendering. In addition for various kinds of objects, we don't bother with cached image surfaces at all, but just render them directly from the draw/expose handler. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A GTK+ roadmap update
Hi Matthias, Thanks for posting this roadmap, and sorry for responding to it a month late. One thing I don't see on that roadmap that I was hoping to see is some mention of new drag-and-drop API. I recall seeing Benjamin talking about it on irc at some point, but I haven't followed up since then. I see one of the items on the list is cross-platform story, and on Windows the selection and drag-and-drop pieces have long been pretty broken. And the APIs are pretty difficult to even understand (at least for me), so that's made it difficult to improve. I have a branch of gtk-2-24 locally that I did a lot of hacking to in an effort to get dnd working better on Win32 using OLE2 and removing the old codepaths (there are like 3 completely different dnd codepaths in the Win32 backend, which makes it even more difficult to understand at first). I got it working for some things but wasn't able to figure out how to get everything working perfectly. The selection and dnd parts of gdk are one of the more awkward parts of the API (or maybe I'm just not smart enough to understand them all well enough). I don't remember exactly what I was blocked on anymore, but if anyone wants it I could clean it up and push the branch to git. If a new drag-and-drop API is still in the stars at some point, I would like to help by implementing the Win32 side of it from the start. Maybe this would help in ironing out the gtk API too. / Cody On Tue, May 6, 2014, at 05:52 AM, Matthias Clasen wrote: > Its been on my todo list for a while to write an update for the GTK+ > roadmap. > > While I couldn't make it to the Developer experience hackfest in > Berlin myself, the GTK+ team was present there and had a pretty > extensive roadmap discussion. Thankfully, they took great notes [1]. I > encourage everybody who is interested in what is planned for the next > year of GTK+ development to read them, they pretty much cover it all. > I have now transcribed them into the more task-oriented form of our > main roadmap page [2]. > > The big themes on the agenda are > 1. Closing gaps for modern applications (widgets missing for GNOME HIG > compliant or Elementary apps) > 2. Improving our cross-platform story > 3. Touch support > 4. Scene graph > 5. Better developer documentation > 6. Closer ties with glade > 7. Cleanups, preparation for 4.0 > > For 3.14, we're aiming to achieve the following: > - Merge the gesture branch > - Add a gtkparasite-lookalike debugging module > - Make Adwaita the default theme > > There are many more details in the notes and on the roadmap page, > including areas where your help could make a difference. So check it > out! ___ 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 Mon, Jun 23, 2014 at 9:59 PM, Paul Davis > wrote: > as Jasper noted in his reply, but i'll describe differently: it is one thing > to draw (even in a separate thread) in a cairo surface that can later to > used during an actual redraw. and certainly many programs have excellent > reasons to do this to speed up redrawing. but this doesn't involving cairo > drawing operations on the surface derived from a GdkWindow. you are drawing > to an image surface that is basically just memory inside your process. you > can do this from any thread, at any time. I am aware of this difference, and Inkscape already renders to intermediate memory surfaces rather than directly to the window in the idle callback, but due to some legacy code it also draws the finished surface to the window in the idle callback. What currently happens is: - draw signal received - queue exposed areas for rendering - render in idle handler - draw to window in idle handler and, as far as I understand, what needs to happen is: - draw signal received - queue exposed areas for rendering - render in separate thread - invalidate part of the window corresponding to the completed rendering - draw result to window in the draw signal handler The only problem we have is that the part of the code that does the above is very old (most of it is around 10 years old) and fairly convoluted, so this change will require some effort. Regards, Krzysztof ___ 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
(sorry, hit send too early)
On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis
wrote:
>
>
>
> On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński
> wrote:
>
>> 2014-06-24 3:02 GMT+02:00 Jasper St. Pierre :
>> > May I ask why you can't paint in the draw signal? GDK already tracks
>> > invalidated windows marked by exposes and gdk_window_invalidate_rect
>> itself.
>> > It should be as efficient as drawing in an idle handler, and also
>> cooperates
>> > with the paint clock, where we can be synchronized to a compositor's
>> redraw
>> > cycle.
>>
>> If all drawing happens in the draw signal and the document has a lot
>> of demanding effects, e.g. SVG filters, it would completely kill
>> responsiveness of the UI. The idle handler solution also allows us
>> easily move drawing to a separate thread in the near future.
>>
>
> Sorry, but I think this is seriously misguided. Have you ever looked at
> the basic structure of the GTK event loop?
>
>while (1) {
>
while (events_pending()) {
process_events (); // queues redraw requests
}
if (higher-than-draw-priority-idle-callbacks) {
call_them ();
}
if (redraws_queued) {
redraw ();
}
if (lower-than-draw-priority-idle-callbacks) {
call_them ();
}
}
all you're doing by using your own idle callbacks for drawing is slightly
moving the precise point at which drawing occurs. using a separate thread
makes this even more convoluted
Now consider future (current!) GTK systems that use a frame clock. The
redraw isn't even supposed to happen on a normal idle, only one where the
frame clock indicates that it is time to draw. On such a system (which
actually reflects the real nature of video hardware for at least the last
decade or two), your redraw-on-idle is not just mildly ineffficient but
totally wrong.
as Jasper noted in his reply, but i'll describe differently: it is one
thing to draw (even in a separate thread) in a cairo surface that can later
to used during an actual redraw. and certainly many programs have excellent
reasons to do this to speed up redrawing. but this doesn't involving cairo
drawing operations on the surface derived from a GdkWindow. you are drawing
to an image surface that is basically just memory inside your process. you
can do this from any thread, at any time.
just don't actually draw it to the window anywhere except a draw event
handler. and when you need the window redrawn, just invalidate the
appropriate areas of the window, and the rest will happen naturally.
___
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
You can draw to a pixbuf or cairo image surface from another thread or in an idle handler, and then paint it to your window in the draw handler. That's probably the best idea, actually. This is what things like the new GtkListBox do -- cache the pixels in a pixel cache, and use that to draw to your window, synchronized with the paint clock. On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński wrote: > 2014-06-24 3:02 GMT+02:00 Jasper St. Pierre : > > May I ask why you can't paint in the draw signal? GDK already tracks > > invalidated windows marked by exposes and gdk_window_invalidate_rect > itself. > > It should be as efficient as drawing in an idle handler, and also > cooperates > > with the paint clock, where we can be synchronized to a compositor's > redraw > > cycle. > > If all drawing happens in the draw signal and the document has a lot > of demanding effects, e.g. SVG filters, it would completely kill > responsiveness of the UI. The idle handler solution also allows us > easily move drawing to a separate thread in the near future. > > In general, the document displayed in Inkscape cannot be drawn in one > piece; it must be rendered as a series of strips that are shown on the > screen once they are ready. Otherwise it takes far too long. > > Although I heavily rewrote the lower levels of Inkscape canvas (those > dealing with SVG objects) to use Cairo and generally cleaned it up, > the upper levels, dealing with editing controls and scheduling the > rendering, are still barely changed from the Sodipodi days. It is > certainly possible to do all drawing in a draw signal, for example by > submitting an invalidate request once a piece of the drawing has > finished rendering, but it will require a nontrivial amount of work. > > Regards, Krzysztof > -- 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 Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński
wrote:
> 2014-06-24 3:02 GMT+02:00 Jasper St. Pierre :
> > May I ask why you can't paint in the draw signal? GDK already tracks
> > invalidated windows marked by exposes and gdk_window_invalidate_rect
> itself.
> > It should be as efficient as drawing in an idle handler, and also
> cooperates
> > with the paint clock, where we can be synchronized to a compositor's
> redraw
> > cycle.
>
> If all drawing happens in the draw signal and the document has a lot
> of demanding effects, e.g. SVG filters, it would completely kill
> responsiveness of the UI. The idle handler solution also allows us
> easily move drawing to a separate thread in the near future.
>
Sorry, but I think this is seriously misguided. Have you ever looked at the
basic structure of the GTK event loop?
while (1) {
>
> In general, the document displayed in Inkscape cannot be drawn in one
> piece; it must be rendered as a series of strips that are shown on the
> screen once they are ready. Otherwise it takes far too long.
>
> Although I heavily rewrote the lower levels of Inkscape canvas (those
> dealing with SVG objects) to use Cairo and generally cleaned it up,
> the upper levels, dealing with editing controls and scheduling the
> rendering, are still barely changed from the Sodipodi days. It is
> certainly possible to do all drawing in a draw signal, for example by
> submitting an invalidate request once a piece of the drawing has
> finished rendering, but it will require a nontrivial amount of work.
>
> Regards, Krzysztof
> ___
> 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
2014-06-24 3:02 GMT+02:00 Jasper St. Pierre : > May I ask why you can't paint in the draw signal? GDK already tracks > invalidated windows marked by exposes and gdk_window_invalidate_rect itself. > It should be as efficient as drawing in an idle handler, and also cooperates > with the paint clock, where we can be synchronized to a compositor's redraw > cycle. If all drawing happens in the draw signal and the document has a lot of demanding effects, e.g. SVG filters, it would completely kill responsiveness of the UI. The idle handler solution also allows us easily move drawing to a separate thread in the near future. In general, the document displayed in Inkscape cannot be drawn in one piece; it must be rendered as a series of strips that are shown on the screen once they are ready. Otherwise it takes far too long. Although I heavily rewrote the lower levels of Inkscape canvas (those dealing with SVG objects) to use Cairo and generally cleaned it up, the upper levels, dealing with editing controls and scheduling the rendering, are still barely changed from the Sodipodi days. It is certainly possible to do all drawing in a draw signal, for example by submitting an invalidate request once a piece of the drawing has finished rendering, but it will require a nontrivial amount of work. Regards, Krzysztof ___ 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
Great eye! Pushed, thanks! I'm sure that's what it was. On Mon, Jun 23, 2014 at 9:41 PM, Colomban Wendling < lists@herbesfolles.org> wrote: > Le 24/06/2014 03:03, Jasper St. Pierre a écrit : > > Thanks, I managed to reproduce the issue with this. It only happens with > > thumbnails visible, though, which suggests that evince is doing > > something funny for the thumbnails view. I'll also check out Scintilla > > later. > > OK, it's fairly obvious after looking at the diff: there's a missing > cairo_surface_destroy() in the new version of gdk_cairo_create(), hence > the surface will probably be leaked and God knows what happens on the > server side. Patch attached. > > Regards, > Colomban > -- 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 24/06/2014 03:03, Jasper St. Pierre a écrit : > Thanks, I managed to reproduce the issue with this. It only happens with > thumbnails visible, though, which suggests that evince is doing > something funny for the thumbnails view. I'll also check out Scintilla > later. OK, it's fairly obvious after looking at the diff: there's a missing cairo_surface_destroy() in the new version of gdk_cairo_create(), hence the surface will probably be leaked and God knows what happens on the server side. Patch attached. Regards, Colomban >From fe2dfe2d85163ac6e04c212402836cd75609948e Mon Sep 17 00:00:00 2001 From: Colomban Wendling Date: Tue, 24 Jun 2014 03:37:59 +0200 Subject: [PATCH] Don't leak the surface in gdk_cairo_create() --- gdk/gdkwindow.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gdk/gdkwindow.c b/gdk/gdkwindow.c index 4e4ec98..68a75df 100644 --- a/gdk/gdkwindow.c +++ b/gdk/gdkwindow.c @@ -3058,6 +3058,8 @@ gdk_cairo_create (GdkWindow *window) cairo_region_destroy (region); cairo_clip (cr); + cairo_surface_destroy (surface); + return cr; } -- 2.0.0 ___ 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 24/06/2014 03:03, Jasper St. Pierre a écrit : > Thanks, I managed to reproduce the issue with this. It only happens with > thumbnails visible, though, which suggests that evince is doing > something funny for the thumbnails view. It happens with no sidebar at all here, so I don't think that's it. Though, as for me scrolling heavily this very PDF with thumbnails is already very slow no matter what (I guess the thumbnails are not cached as well as the real view or something, but large page range change eats lots of normal CPU time), it can just be stressing the drawing a little more. Also, I can't seem to reproduce with any older revision, like 240daf55a193efd5cc83bb838a14e57ad4ce90ab works just fine, and I bisected since 0ec00ffbb04796546785fcd4fa8df092b8564e43; so I don't think it's really the application's fault here. 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
Hi, On Mon, Jun 23, 2014 at 9:03 PM, Jasper St. Pierre wrote: > Thanks, I managed to reproduce the issue with this. It only happens with > thumbnails visible, though, which suggests that evince is doing something > funny for the thumbnails view. I'll also check out Scintilla later. > slow scroll with thumbnails visible is a known bug of Evince since 3.0... Basically we read the thumbnails on the fly and then change the model on a GtkIconView... Since GtkIconView recomputes the hfw (or the wfh don't remember) each time you modify the model (since gtk 3)... each time we read a thumbnail we do a relayout... so yes, we are doing something funny with thumbnails, and slow scroll should have nothing to do with these patches (although It might get more noticeable if other apps are slugish too) Greets José > > On Mon, Jun 23, 2014 at 8:19 PM, Colomban Wendling < > lists@herbesfolles.org> wrote: > >> Le 24/06/2014 02:03, Jasper St. Pierre a écrit : >> > I can't reproduce any issue in scrolling with evince locally -- does it >> > only happen with certain documents? Can you point to a document where >> > you have problems? >> >> I doubt it's document-related, as it "worked" with the first three PDFs >> I tried with. Anyway, I can reproduce with e.g. >> http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf Note however >> that you have to scroll *aggressively*, meaning I'm was assaulting my >> mouse wheel for several seconds, or take the scrollbar grip and shake it >> quick. Also it's less directly visible with Evince itself which seems >> to have a very cheap scroll draw (yet you probably notice something), >> but other apps gets slow-slow (for example gedit's gear menu takes like >> 5s to open). >> >> I also just tried to enable Metacity's compositing as I was using it >> without, and I can reproduce with and without compositing. >> >> > I also just built Scintilla and SCiTE from source, but they both appear >> > to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or >> > port, or did I do something wrong when building Scintilla/SCiTE? >> >> you need to set the GTK3 make variable to 1: >> >> $ cd gtk >> $ make GTK3=1 >> >> Regards, >> Colomban > > > -- > 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
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Thanks, I managed to reproduce the issue with this. It only happens with thumbnails visible, though, which suggests that evince is doing something funny for the thumbnails view. I'll also check out Scintilla later. On Mon, Jun 23, 2014 at 8:19 PM, Colomban Wendling < lists@herbesfolles.org> wrote: > Le 24/06/2014 02:03, Jasper St. Pierre a écrit : > > I can't reproduce any issue in scrolling with evince locally -- does it > > only happen with certain documents? Can you point to a document where > > you have problems? > > I doubt it's document-related, as it "worked" with the first three PDFs > I tried with. Anyway, I can reproduce with e.g. > http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf Note however > that you have to scroll *aggressively*, meaning I'm was assaulting my > mouse wheel for several seconds, or take the scrollbar grip and shake it > quick. Also it's less directly visible with Evince itself which seems > to have a very cheap scroll draw (yet you probably notice something), > but other apps gets slow-slow (for example gedit's gear menu takes like > 5s to open). > > I also just tried to enable Metacity's compositing as I was using it > without, and I can reproduce with and without compositing. > > > I also just built Scintilla and SCiTE from source, but they both appear > > to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or > > port, or did I do something wrong when building Scintilla/SCiTE? > > you need to set the GTK3 make variable to 1: > > $ cd gtk > $ make GTK3=1 > > Regards, > Colomban -- 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
May I ask why you can't paint in the draw signal? GDK already tracks invalidated windows marked by exposes and gdk_window_invalidate_rect itself. It should be as efficient as drawing in an idle handler, and also cooperates with the paint clock, where we can be synchronized to a compositor's redraw cycle. On Mon, Jun 23, 2014 at 8:53 PM, Krzysztof Kosiński wrote: > 2014-06-21 3:00 GMT+02:00 Jasper St. Pierre : > > 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. > > This will also break the GTK 3 version of Inkscape, which paints its > canvas in an idle handler, and the draw signal only marks areas for > redraw. However, it may be fixable by using the begin_paint APIs. > > Regards, Krzysztof > -- 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
2014-06-21 3:00 GMT+02:00 Jasper St. Pierre : > 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. This will also break the GTK 3 version of Inkscape, which paints its canvas in an idle handler, and the draw signal only marks areas for redraw. However, it may be fixable by using the begin_paint APIs. Regards, Krzysztof ___ 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 24/06/2014 02:03, Jasper St. Pierre a écrit : > I can't reproduce any issue in scrolling with evince locally -- does it > only happen with certain documents? Can you point to a document where > you have problems? I doubt it's document-related, as it "worked" with the first three PDFs I tried with. Anyway, I can reproduce with e.g. http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf Note however that you have to scroll *aggressively*, meaning I'm was assaulting my mouse wheel for several seconds, or take the scrollbar grip and shake it quick. Also it's less directly visible with Evince itself which seems to have a very cheap scroll draw (yet you probably notice something), but other apps gets slow-slow (for example gedit's gear menu takes like 5s to open). I also just tried to enable Metacity's compositing as I was using it without, and I can reproduce with and without compositing. > I also just built Scintilla and SCiTE from source, but they both appear > to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or > port, or did I do something wrong when building Scintilla/SCiTE? you need to set the GTK3 make variable to 1: $ cd gtk $ make GTK3=1 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
I can't reproduce any issue in scrolling with evince locally -- does it only happen with certain documents? Can you point to a document where you have problems? I also just built Scintilla and SCiTE from source, but they both appear to be using GTK+ 2, not GTK+ 3. Are you using some unofficial fork or port, or did I do something wrong when building Scintilla/SCiTE? On Mon, Jun 23, 2014 at 7:45 PM, Colomban Wendling < lists@herbesfolles.org> wrote: > Le 24/06/2014 00:02, Jasper St. Pierre a écrit : > > Hey everyone again > > > > [...] > > > > 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 > > > > [...] > > > > 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. > > Sorry, but apparently 984e811c16891cb4945a090bea8ec9e81ce3dba6 (result > of a bisect) breaks badly in some situation. With it, if I scroll > aggressively in some apps (at least Evince and SciTE) I can get the X > server to start consuming extreme CPU (even after the scroll ended). > > Not only the application gets extremely slugish, but other apps too, > e.g. scrolling a terminal is equally slow and consumes resources, as > well as drawing other apps. > > However, as soon as I close the initial app, everything comes back to > normal. > > I don't know really how to debug this, but tell me if I can do anything. > > Regards, > Colomban > ___ > 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
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
Le 24/06/2014 00:02, Jasper St. Pierre a écrit : > Hey everyone again > > [...] > > 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 > > [...] > > 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. Sorry, but apparently 984e811c16891cb4945a090bea8ec9e81ce3dba6 (result of a bisect) breaks badly in some situation. With it, if I scroll aggressively in some apps (at least Evince and SciTE) I can get the X server to start consuming extreme CPU (even after the scroll ended). Not only the application gets extremely slugish, but other apps too, e.g. scrolling a terminal is equally slow and consumes resources, as well as drawing other apps. However, as soon as I close the initial app, everything comes back to normal. I don't know really how to debug this, but tell me if I can do anything. 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, 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 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 > 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
Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed
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 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 > 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 > ___ 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
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 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
