Ugly flashing behavior in Photon (Re-post)

I’m looking for a way to reduce the flashing when I update either:
a) right-justified text to a PtText widget or
b) sample-points to an RtTrend widget.
I’m using a 20 millisec repeating PtTimer callback to update the widgets and
I see kind of a beat frequency (rolling) blink through these display
controls.

I know its not my hardware - it runs the QNX Trend demo app just fine with
no update flashing.

I have tried about everything I can think of. QNX tech folks had me upgrade
from Photon 1.13 to 1.14 - but no joy there. Anyone seen this or have any
ideas???

Jay Marchetti
Pittsburgh Firmware

Jay Marchetti <marchetti@pittsburghfirmware.com> wrote:

I’m looking for a way to reduce the flashing when I update either:
a) right-justified text to a PtText widget or
b) sample-points to an RtTrend widget.
I’m using a 20 millisec repeating PtTimer callback to update the widgets and
I see kind of a beat frequency (rolling) blink through these display
controls.

I know its not my hardware - it runs the QNX Trend demo app just fine with
no update flashing.

I have tried about everything I can think of. QNX tech folks had me upgrade
from Photon 1.13 to 1.14 - but no joy there. Anyone seen this or have any
ideas???

Make the widgets that are flashing children of a PtDBContainer
widget – it draws all of its contents as one block, removing the
flicker effect.



Norbert Black
QSSL Training Services

This works great for the PtText widgets, but I see no RtTrend object visible
at run-time if it is a PtDBContainer child. Is there some other arguments
(of either the PtDBContainer of RtTrend widgets) that I need to set? Read
the help & tried IMAGE_TYPE arg to no avail… Any guidance you can offer
here Norbert?

By the way, this right-justified PtText blinking has been vexing me for > 6
months. QNX tech support did not have any ideas on it. A big improvement -
Thanks Norbert.

Jay

Norbert Black <nblack@qnx.com> wrote in message
news:92thbg$1ec$1@nntp.qnx.com

Jay Marchetti <> marchetti@pittsburghfirmware.com> > wrote:
I’m looking for a way to reduce the flashing when I update either:
a) right-justified text to a PtText widget or
b) sample-points to an RtTrend widget.
I’m using a 20 millisec repeating PtTimer callback to update the widgets
and
I see kind of a beat frequency (rolling) blink through these display
controls.

I know its not my hardware - it runs the QNX Trend demo app just fine
with
no update flashing.

I have tried about everything I can think of. QNX tech folks had me
upgrade
from Photon 1.13 to 1.14 - but no joy there. Anyone seen this or have
any
ideas???

Make the widgets that are flashing children of a PtDBContainer
widget – it draws all of its contents as one block, removing the
flicker effect.



Norbert Black
QSSL Training Services

“Norbert Black” <nblack@qnx.com> wrote in message
news:92thbg$1ec$1@nntp.qnx.com

Jay Marchetti <> marchetti@pittsburghfirmware.com> > wrote:
I’m looking for a way to reduce the flashing when I update either:
a) right-justified text to a PtText widget or
b) sample-points to an RtTrend widget.
I’m using a 20 millisec repeating PtTimer callback to update the widgets
and
I see kind of a beat frequency (rolling) blink through these display
controls.

I know its not my hardware - it runs the QNX Trend demo app just fine
with
no update flashing.

I have tried about everything I can think of. QNX tech folks had me
upgrade
from Photon 1.13 to 1.14 - but no joy there. Anyone seen this or have
any
ideas???

Make the widgets that are flashing children of a PtDBContainer
widget – it draws all of its contents as one block, removing the
flicker effect.

At 50Hz, that might not work. PtDBContainer slows the update process a
fair bit. Out of curiosity, why do you need to update the display at 50Hz?
Humans cannot discern animation frequencies above 27Hz, and cannot
read numbers at even lower frequencies than that (5-10 Hz?). If your data
rate
is 50Hz, you could de-couple the input data rate from the display rate, and
put
your screen updates on a 500ms timer. Then the PtDBContainer would work
well.

Andrew

Jay Marchetti <marchetti@pittsburghfirmware.com> wrote:

This works great for the PtText widgets, but I see no RtTrend object visible
at run-time if it is a PtDBContainer child. Is there some other arguments
(of either the PtDBContainer of RtTrend widgets) that I need to set? Read
the help & tried IMAGE_TYPE arg to no avail… Any guidance you can offer
here Norbert?

Hmmm. Sorry, not really. The RtTrend widget does appear as a
child of a PtDBContainer quite happily in any sample I’ve ever
tried. Maybe there’s something odd/interesting about how you’re
trying to make it appear? Did you set the poor elusive beastie
up in PhAB, or are you creating it at runtime? If you do a
PtGetResources() call on it at runtime, does its Pt_ARG_POS
resource give a position that is actually within the extent of
its parent? I’ve known folks that created widgets from code, and
gave them a position that would be clipped by the parent.

By the way, this right-justified PtText blinking has been vexing me for > 6
months.

I still don’t really have any idea why right justification
would flicker, and not left-justified text. :confused: Something about
how the font engine works hitting a sour spot in your refresh
rate? Colour me confused…

Anyway, the “dump it in a PtDBContainer” stunt is pretty standard
Photon 1.1x procedure for anything that gives flicker. It has
some drawbacks in terms of speed/overhead, as a later poster in
this thread mentions. There is a chapter on Animation in the
Photon programmer’s guide with some stuff on getting rid of
flicker (Programmer’s Guide/Raw Drawing and Animation/Animation/
Flickerless Animation) that goes into rather more detail. You
may want to play with memory contexts yourself – worth
investigating, anyway.

QNX tech support did not have any ideas on it.

Having come from TS myself, I have sympathies for them. It’s
hell trying to be an expert on everything (I know I never
managed… :slight_smile: ). Hopefully they’ll drop this one into the
knowledge base so that the next person along can have the
connection made for them.

Thanks Norbert.

No problem. Good luck with the PtDBContainer.



Norbert Black
QSSL Training Services

Andrew:

The application is a motion controller where the numbers are actually
changing at a very high (5KHz) rate. Sub-sampling at 50 Hz was rather
arbitrary, though I want it fast because for this application the perceived
rate of change in the number’s magnitudes (which represent analog real-world
quantities like position, velocity, etc.) with time is usually more
important than reading the exact value of each sub-sample.

Hence, 2 Hz (500 millisec) would be way too coarse, e.g. imagine a digital
speedometer readout in your car that updates once per 10 seconds - a Nyquist
rate is hard-wired into our brain such that humans cannot intuitively
perceive this as an analog quantity that is changing continuously with time.
For things like chemical process control systems, with time constants in
minutes or hours, this is not really a concern; but in motion control, it
definitely is.

Back to nuts & bolts: Thing is, the PtText update (at 50 Hz) works just fine
as a PtDBContainer child - and does not blink. BTW: I see blinking on PtText
updates ONLY if the horizontal allignment is Center or Right, e.g. not Left,
which is blinkless at 50 Hz.

I’ll work with it some more to see if I can get the RtTrend widget to work
just as well.

-Jay

Andrew Thomas <andrew-s-thomas@home.nospam.com> wrote in message
news:92tut3$7ac$1@inn.qnx.com

“Norbert Black” <> nblack@qnx.com> > wrote in message
news:92thbg$1ec$> 1@nntp.qnx.com> …
Jay Marchetti <> marchetti@pittsburghfirmware.com> > wrote:
I’m looking for a way to reduce the flashing when I update either:
a) right-justified text to a PtText widget or
b) sample-points to an RtTrend widget.
I’m using a 20 millisec repeating PtTimer callback to update the
widgets
and
I see kind of a beat frequency (rolling) blink through these display
controls.

I know its not my hardware - it runs the QNX Trend demo app just fine
with
no update flashing.

I have tried about everything I can think of. QNX tech folks had me
upgrade
from Photon 1.13 to 1.14 - but no joy there. Anyone seen this or have
any
ideas???

Make the widgets that are flashing children of a PtDBContainer
widget – it draws all of its contents as one block, removing the
flicker effect.

At 50Hz, that might not work. PtDBContainer slows the update process a
fair bit. Out of curiosity, why do you need to update the display at
50Hz?
Humans cannot discern animation frequencies above 27Hz, and cannot
read numbers at even lower frequencies than that (5-10 Hz?). If your data
rate
is 50Hz, you could de-couple the input data rate from the display rate,
and
put
your screen updates on a 500ms timer. Then the PtDBContainer would work
well.

Andrew

OK, found out that the RtTrend was blinking because I was setting the
resources Rt_ARG_TREND_COLOR_LIST and Rt_ARG_TREND_ATTRIBUTES repeatedly
e.g. within my 20 millisec timer callback, in addition to adding new points
with Rt_ARG_TREND_DATA.

I moved the setup code over to a window post-realized function and voila -
nice smoothe trends w/o blinking and w/o using the PtDBContainer. However,
the PtDBContainer is still a great find for updating PtText widgets w/o
blinking.

Thanks again Norbert…

Jay Marchetti
Pittsburgh Firmware
www.pittsburghfirmware.com

Jay Marchetti <marchetti@pittsburghfirmware.com> wrote in message
news:92vetq$4md$1@inn.qnx.com

Andrew:

The application is a motion controller where the numbers are actually
changing at a very high (5KHz) rate. Sub-sampling at 50 Hz was rather
arbitrary, though I want it fast because for this application the
perceived
rate of change in the number’s magnitudes (which represent analog
real-world
quantities like position, velocity, etc.) with time is usually more
important than reading the exact value of each sub-sample.

Hence, 2 Hz (500 millisec) would be way too coarse, e.g. imagine a digital
speedometer readout in your car that updates once per 10 seconds - a
Nyquist
rate is hard-wired into our brain such that humans cannot intuitively
perceive this as an analog quantity that is changing continuously with
time.
For things like chemical process control systems, with time constants in
minutes or hours, this is not really a concern; but in motion control, it
definitely is.

Back to nuts & bolts: Thing is, the PtText update (at 50 Hz) works just
fine
as a PtDBContainer child - and does not blink. BTW: I see blinking on
PtText
updates ONLY if the horizontal allignment is Center or Right, e.g. not
Left,
which is blinkless at 50 Hz.

I’ll work with it some more to see if I can get the RtTrend widget to work
just as well.

-Jay

Andrew Thomas <> andrew-s-thomas@home.nospam.com> > wrote in message
news:92tut3$7ac$> 1@inn.qnx.com> …

“Norbert Black” <> nblack@qnx.com> > wrote in message
news:92thbg$1ec$> 1@nntp.qnx.com> …
Jay Marchetti <> marchetti@pittsburghfirmware.com> > wrote:
I’m looking for a way to reduce the flashing when I update either:
a) right-justified text to a PtText widget or
b) sample-points to an RtTrend widget.
I’m using a 20 millisec repeating PtTimer callback to update the
widgets
and
I see kind of a beat frequency (rolling) blink through these display
controls.

I know its not my hardware - it runs the QNX Trend demo app just
fine
with
no update flashing.

I have tried about everything I can think of. QNX tech folks had me
upgrade
from Photon 1.13 to 1.14 - but no joy there. Anyone seen this or
have
any
ideas???

Make the widgets that are flashing children of a PtDBContainer
widget – it draws all of its contents as one block, removing the
flicker effect.

At 50Hz, that might not work. PtDBContainer slows the update process a
fair bit. Out of curiosity, why do you need to update the display at
50Hz?
Humans cannot discern animation frequencies above 27Hz, and cannot
read numbers at even lower frequencies than that (5-10 Hz?). If your
data
rate
is 50Hz, you could de-couple the input data rate from the display rate,
and
put
your screen updates on a 500ms timer. Then the PtDBContainer would work
well.

Andrew

\

“Jay Marchetti” <marchetti@pittsburghfirmware.com> wrote in message
news:92vetq$4md$1@inn.qnx.com

Andrew:

The application is a motion controller where the numbers are actually
changing at a very high (5KHz) rate. Sub-sampling at 50 Hz was rather
arbitrary, though I want it fast because for this application the
perceived
rate of change in the number’s magnitudes (which represent analog
real-world
quantities like position, velocity, etc.) with time is usually more
important than reading the exact value of each sub-sample.

Hence, 2 Hz (500 millisec) would be way too coarse, e.g. imagine a digital
speedometer readout in your car that updates once per 10 seconds - a
Nyquist
rate is hard-wired into our brain such that humans cannot intuitively
perceive this as an analog quantity that is changing continuously with
time.
For things like chemical process control systems, with time constants in
minutes or hours, this is not really a concern; but in motion control, it
definitely is.

Hi Jay. If you are really trying to convey the rate-of-change and
percent-of-scale
information, have you considered using a slider or progress bar? PtText is
a very
CPU intensive widget relative to bars and text-less meters. Then again,
reading
on in your message, you are getting good performance from PtText, so the
point
may be moot.

Can you put the RtTrend on a different timer? If you add data to the trend
at
5 Hz, for example, but put up 10 points per refresh, you still show 50hz
sub-
sampled data, but with a much more achievable frame rate. This may be fast
enough to satisfy the user, and of course you could play around with any
even
divisor of your 50Hz until you got something that looked good.

Regards,
Andrew

Andrew:

Good suggestion on putting RtTrend on a slower timer. Thanks for the
input…

-Jay

Andrew Thomas <andrew-s-thomas@home.nospam.com> wrote in message
news:930t03$t4t$1@inn.qnx.com

“Jay Marchetti” <> marchetti@pittsburghfirmware.com> > wrote in message
news:92vetq$4md$> 1@inn.qnx.com> …
Andrew:

The application is a motion controller where the numbers are actually
changing at a very high (5KHz) rate. Sub-sampling at 50 Hz was rather
arbitrary, though I want it fast because for this application the
perceived
rate of change in the number’s magnitudes (which represent analog
real-world
quantities like position, velocity, etc.) with time is usually more
important than reading the exact value of each sub-sample.

Hence, 2 Hz (500 millisec) would be way too coarse, e.g. imagine a
digital
speedometer readout in your car that updates once per 10 seconds - a
Nyquist
rate is hard-wired into our brain such that humans cannot intuitively
perceive this as an analog quantity that is changing continuously with
time.
For things like chemical process control systems, with time constants in
minutes or hours, this is not really a concern; but in motion control,
it
definitely is.

Hi Jay. If you are really trying to convey the rate-of-change and
percent-of-scale
information, have you considered using a slider or progress bar? PtText
is
a very
CPU intensive widget relative to bars and text-less meters. Then again,
reading
on in your message, you are getting good performance from PtText, so the
point
may be moot.

Can you put the RtTrend on a different timer? If you add data to the
trend
at
5 Hz, for example, but put up 10 points per refresh, you still show 50hz
sub-
sampled data, but with a much more achievable frame rate. This may be
fast
enough to satisfy the user, and of course you could play around with any
even
divisor of your 50Hz until you got something that looked good.

Regards,
Andrew