Hi Frederik,
>>>>> <frede...@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, frede...@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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
