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

[Paul Davis <paul linuxaudiosystems com>]

(sorry, hit send too early)

On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis <paul linuxaudiosystems com> wrote:

On Mon, Jun 23, 2014 at 9:57 PM, Krzysztof Kosiński <tweenk pl gmail com> wrote:

2014-06-24 3:02 GMT+02:00 Jasper St. Pierre <jstpierre mecheye net>:

> 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.