Graphical sinks and visibility state

It looks like when a graphic sink isn’t visible, it doesn’t “run”.

Is there a clean way to override this behaviour?

For some types of graphical outputs, like waterfall sinks, which show a
time series, having that waterfall
stop, simply because it isn’t currently visible, is broken. If you
have said waterfall in a multi-tab
“notebook” for example, and you’re currently looking at another tab,
that waterfall won’t run, and
you can miss temporal trends in the data. Is there an easy way to
turn that not-correct-in-many-cases
behaviour off?

Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On Wed, Apr 28, 2010 at 00:06, Marcus D. Leech [email protected]

It looks like when a graphic sink isn’t visible, it doesn’t “run”.

This was an optimization for performance. One can quickly run out of
CPU by having multiple notebook tabs with display sinks in them.

It could be made configurable, but there is a fair amount of surgery


On 04/28/2010 02:18 PM, Johnathan C. wrote:


This raises another point–quite a lot of the runtime behaviour of the
graphic sinks is only
controllable via the GUI controls, and there’s no programmatic way to
set them (that I could
find–I’d be pleased to be proven wrong).

For example, the Trigger mode, time offset, etc, are only controllable
via the GUI. You can’t
even set them at init time when you create the object.

A usable, consistent, mechanism needs to be in place to make sure that
all of the behaviour
that is controllable using a GUI control can also be controlled
programmatically (which also
implies, can be saved in a config file, etc, etc).

I put in a HORRIBLE KLUDGE into to allow for the
oscope to come up with
gr_TRIG_MODE_STIPCHART set on init, but I’m not going to propagate
that kludge into
the repos :slight_smile: I used an environment variable. When it’s creating
the object, it checks
to see if OSCOPE_TRIG_MODE is set to STRIPCHART, and configs the
oscope appropriately.
But golly, that’s, ahem, ugly and braindead.

Principal Investigator
Shirleys Bay Radio Astronomy Consortium

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs