[Rd] getGraphicsEvent on X11 and event queuing

[Martin Maechler]

Hi Frederik,

>>>>>   <frederik at ofb.net>
>>>>>     on Tue, 7 Jun 2016 15:20:05 -0700 writes:

    > ... I just realized that setGraphicsEventHandlers or
    > getGraphicsEvent could have an 'onIdle' callback, to be
    > called somewhere in the polling loop of gevents.c:163 - I
    > think this would solve my problem #2 in a minimally
    > disruptive way.

I hope you will get some feedback about this by one of the
graphics/devices experts from within R core.
I'm not among them at all, but they may be busy or travelling
currently.

Also, as you are studying the C code and the issues anyway, it
may be worthwhile to consider (as small as possible!) patches to
the source you could also post to the bugzilla site if you
prefer; attaching as text/plain to R-devel does work fine, too.

Best regards,
Martin

    > On Mon, Jun 06, 2016 at 06:38:45PM -0700, frederik at ofb.net
    > wrote:
    >> Hi R-Devel,
    >> 
    >> I've been working on an oscilloscope project using an
    >> Arduino microcontroller board. I found that it's quite
    >> easy to get realtime updates, e.g. 30+ frames per second,
    >> if I read data from the board in a little Rcpp library. I
    >> have to use dev.hold() and dev.flush() to keep the plot
    >> from flickering, which restricts me to the "cairo" X11
    >> device.
    >> 
    >> I'd like to be able to add interactivity to the
    >> oscilloscope display, for instance to bind a key to save
    >> the current plot to a file, or to bind keys for adjusting
    >> the time scale etc.
    >> 
    >> However, I ran into two problems:
    >> 
    >> (1) setGraphicsEventHandlers only works on the "Xlib" X11
    >> device, which doesn't support buffering via dev.hold() -
    >> it flickers.
    >> 
    >> (2) getGraphicsEvent and friends lack some interface
    >> features which are needed to use the functions in an
    >> asynchronous fashion. Typically, event listener library
    >> functions have a "timeout" parameter, and the ability to
    >> return already-queued events. But getGraphicsEvent() has
    >> neither - it waits indefinitely (you can't set a
    >> timeout), and it seems to ignore events which occurred
    >> before it was called (I can't figure out why, from the
    >> code, I guess the normal R event processing grabs events
    >> which occur between calls to getGraphicsEvent?).
    >> 
    >> It seems like it should be possible to set a handler for
    >> keyboard events and have it execute in between plot
    >> updates when the user presses a key - yet without
    >> blocking further updates if no key has been pressed.
    >> 
    >> Is anyone interested in fixing (1) and (2)? Or is there
    >> some other library or workaround to solve my problems?
    >> 
    >> Here is some code I used to play around with these
    >> functions:
    >> 
    >> X11(type="Xlib");
    >> 
    >> keydown = function(key) { cat("Got key: ",key); lastkey <<- key }
    >> 
    >> setGraphicsEventHandlers(onKeybd = keydown);
    >> 
    >> plot(c(0,0)); getGraphicsEvent();
    >> 
    >> Well, I think it's great that getGraphicsEvent exists at
    >> all, and want to salute Duncan Murdoch who is listed as
    >> the author. I hope I may have helped by describing some
    >> new possible uses for these functions.
    >> 
    >> Thank you,
    >> 
    >> Frederick
    >> 
    >> ______________________________________________
    >> R-devel at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> 

    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel