Hi; On 30 March 2015 at 18:56, dmg <d...@uvic.ca> wrote:
> On Mon, Mar 30, 2015 at 5:22 AM, Emmanuele Bassi <eba...@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. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
