Re: gtk_widget_queue_draw_area much slower in gtk3 than gtk3

[Jim Charlton <charltn gmail com>]

On 15-03-30 11:13 AM, Emmanuele Bassi wrote:
> Hi;
>
> On 30 March 2015 at 18:56, dmg <dmg uvic ca> wrote:
>
> > On Mon, Mar 30, 2015 at 5:22 AM, Emmanuele Bassi <ebassi gmail com> wrote:
> > > Motion events are compressed in GTK+; they get collected and pushed to
> > > the application code once per frame, because you cannot obviously
> > > paint any faster than what your display can show, and because the vast
> > > majority of applications do not draw content in response to fine event
> > > delivery.
> > Please see this: https://github.com/xournalpp/xournalpp/issues/109
> > it exemplifies the problem we have from gtk2 to gtk3.
> >
> > I did a small test. I tried to draw a curve during 1 second. And the
> > results seem to support this as the reason.
> >
> >   in the motion notify event our logic is the following:
> >
> > 1- We gather the coordinates of the new point
> > 2- Using cairo we draw the new line segment directly onto the canvas
> What does drawing "directly onto the canvas" mean, in this context?
>
> > 3- We then compute the area that the new segment occupies
> > 4- We call gtk_widget_queue_draw_area synchronously
> What does "call gtk_widget_queue_draw_area" synchronously mean, in this context?
>
> > When 4 is removed, sampling increases significantly and we no longer
> > have the problem but now the screen is not refreshed immediately. It
> > is random when the refresh is.
> That sounds… impressively wrong.
>
> Are you getting a cairo_t* from the GdkWindow used by the widget and
> just drawing on it?
>
> Are you drawing on an image surface and then using the image surface
> as the source for the cairo_t* in the GtkWidget::draw signal handler?
>
> Are you using a thread to avoid blocking the UI from the event handler
> while you draw on an offscreen surface?
>
> > It seems to me that the problem is the that we call
> > gtk_widget_queue_draw_area every time we have a segment.
> No, that's definitely not the problem.
>
> > The refresh rate of rendering seems to imply that we can only call
> > gtk_widget_queue_draw once every 1/60s. (or whatever refresh rate the
> > computer has)
> > but what would be the best way to do this? If the user is drawing at a
> > rate of one point in less than 1/60s then do not use
> > gtk_widget_queue_draw.
> No.
>
> *Redrawing* is what happens at the same refresh rate as the display.
> You cannot draw any faster, so there's no point in doing anything else
> anyway. Motion events received in between frames are also compressed,
> and the event-related signals will be emitted only at the beginning of
> the frame; that's what disabling the event compression undoes — you'll
> get events as soon as they arrive from the windowing system.
>
> What it seems to be your problem is that you expect to be able to draw
> at any point on the actual surface of the widget, which does not
> really work — it didn't work in GTK+ 2 either, it just "happened" to
> work because of how internally GTK shuffled the processing of each
> frame.
>
> In order to give you a better answer, I'll need some more context on
> what you are doing; I apologize, but I honestly don't have time to go
> through your code base at the moment, so a description (with links to
> the code) would be most helpful.
>
> Ciao,
>   Emmanuele.
Just as an aside on this issue...  the mouse sampling rate on my Linux 
Ubuntu desktop is 125 Hz.  Given that I can swipe across the screen in 
about 1/10th of a second, that leaves me with only 10 events for the 
width of the screen.  So it would be impossible to expect that you could 
get a more continuous line of points.  To do so would require you to 
increase the sampling rate (which can be done) or, obviously, to move 
the mouse more slowly.  But I suppose that this discussion really is 
more about the limitations imposed by the redraw rather than the 
sampling rate.... or is it???

Jim Charlton