Double-Buffering over a phrelay link.

QNX Newsgroups (Archives) qdn.public.qnx4.photon
1

Does anybody know of a way to set up photon applications to use
double-buffering when running over a phrelay (phindows/phinx) link?

I have a remote monitoring application that must be accessed through a
modem link (~12kbps). Running the Photon-based GUI over this link works
reasonably well except that the widgets keep appearing and disappearing
dependent I assume on what phase of redraw they are in. The screen has a
fair bit of data that is being continuously updated, including labels, bar
graphs, and RtTrend objects. Even over a lan connection the lack of
double-buffering makes the GUI quite jittery.

Any recommendations on how to get rid of these widget jitters would be
appreciated.

Mike

2

Hi

I seem to recall several employers ago that we had an audio production
application that they wanted to use over a modem. We had several VU meters
on the screen and there was no way that they could be constantly sent over a
slow modem.

We had to do something to detect that there was a slow modem link and
significanly slow down the updates on the VU meters.

I don’t think that double buffering is really going to help. It will just
delay the inevetable. You just can’t get 5 lbs of shrimp in a 3 lb bag.

(For those of you who don’t undersrtand, just substitute kg. for lb.)

–
Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net

“Michael Hambly” <michael@blackbirdsoftware.com> wrote in message
news:3BE34982.15C4B09D@blackbirdsoftware.com…

Does anybody know of a way to set up photon applications to use
double-buffering when running over a phrelay (phindows/phinx) link?

I have a remote monitoring application that must be accessed through a
modem link (~12kbps). Running the Photon-based GUI over this link works
reasonably well except that the widgets keep appearing and disappearing
dependent I assume on what phase of redraw they are in. The screen has a
fair bit of data that is being continuously updated, including labels, bar
graphs, and RtTrend objects. Even over a lan connection the lack of
double-buffering makes the GUI quite jittery.

Any recommendations on how to get rid of these widget jitters would be
appreciated.

Mike

3

Thanks for the advice Bill, but its not so much the size of the pipe that is
the problem. We can live with slightly slower updates. In fact we tried slowing
down our redraw frequency to put constraints on the bandwidth usage. That
actually made the visual effect worse though. As we slowed things down the
anomalies would simply tend to remain on screen longer.

The problem is that the widgets are being displayed in the middle of being
redrawn. For example, on a couple of screens we use the RtTrend object to
display data trends. These trends are only updated once every 15 seconds. The
problem is that it is not the final result of the redraw that is displayed.
Instead the view of the widget that we are presented with will alternate (in no
particular order) between not being there at all, showing the background fill
colour only, showing the background with the grid, or showing the final result
of the redraw with background, grid and trends. All the other widgets behave
similarly. They disappear, and then reappear, dependent upon which phase of
their redraw they are caught in.

Even over a 100 Mbps lan connection, we still see the effect of the lack of
double-buffering because the widgets on the screen will flash each time as they
are redrawn. In this case we do not have to put up with the effect of seeing
the widget in mid-redraw because the redraw is done so quickly. However, the
classical single-bit plane effect of widget flash remains.

Again, any advice on how to resolve this problem would be appreciated.

–
Michael Hambly
Blackbird Software Design Ltd.
http://www.blackbirdsoftware.com, mailto:michael@blackbirdsoftware.com
phone: 1-403-678-3002, fax: 1-403-609-2718


Bill Caroselli wrote:

Hi

I seem to recall several employers ago that we had an audio production
application that they wanted to use over a modem. We had several VU meters
on the screen and there was no way that they could be constantly sent over a
slow modem.

We had to do something to detect that there was a slow modem link and
significanly slow down the updates on the VU meters.

I don’t think that double buffering is really going to help. It will just
delay the inevetable. You just can’t get 5 lbs of shrimp in a 3 lb bag.

(For those of you who don’t undersrtand, just substitute kg. for lb.)

–
Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net

“Michael Hambly” <> michael@blackbirdsoftware.com> > wrote in message
news:> 3BE34982.15C4B09D@blackbirdsoftware.com> …
Does anybody know of a way to set up photon applications to use
double-buffering when running over a phrelay (phindows/phinx) link?

I have a remote monitoring application that must be accessed through a
modem link (~12kbps). Running the Photon-based GUI over this link works
reasonably well except that the widgets keep appearing and disappearing
dependent I assume on what phase of redraw they are in. The screen has a
fair bit of data that is being continuously updated, including labels, bar
graphs, and RtTrend objects. Even over a lan connection the lack of
double-buffering makes the GUI quite jittery.

Any recommendations on how to get rid of these widget jitters would be
appreciated.

Mike

4

This advice is based on my limited understanding of Photon,
so please take this with some salt.
Hopefully the experts will jump in soon.

I wonder if this hasn’t to do with widgets being “damaged”, so Photon deciding to
redraw.
I’ve had a similar case, where the application was implemented using a lot
of overlapping widgets, and an update function potentially updating
the display every 100ms (e.g. even if nothing changed, it would still do
the setresource/setwidget thingy).
I ended up maintaining my own state of updates/damage, and not relying on
Photon’s states, and the flickering went away.

You may also want to check the sequence of your widgets, if you have
overlap of widgets.
Widgets will be redrawn starting furthest away from the screen
and moving towards you. It may be that a widget deep in is
being changed, and thus causing a redraw all the way to the front.

This all said, I would think that because of its nature RtTrend will cause
a lot of redrawing to happen every time the trend has to be updated.

Have you tried to simplify e.g. what happens .e.g with just RtTrend,
with no other widgets in the application?

5

Thanks Alex. Your suggestion makes sense.

I’ll look over my widget layout and code more closely. As I suspect that there is
probably no support for double-buffering over phrelay, your suggestions about
avoiding widget overlaps and maintaining a separate update table may be the best
way of resolving this problem. I do keep a very macro level state flag for refreshes
at present, but I may need to monitor for changes on individual widgets instead. It
won’t solve my problem totally but maybe I can improve the results a bit.

You’ve also given me an idea for working around the RtTrend problem. I’m thinking
that perhaps if I turn off the grid when running over a modem I may be able to
reduce the number of cycles for the redraw. Time to experiment.

Thanks,

Michael Hambly
Blackbird Software Design Ltd.
http://www.blackbirdsoftware.com, mailto:michael@blackbirdsoftware.com
phone: 1-403-678-3002, fax: 1-403-609-2718

Alex Cellarius wrote:

This advice is based on my limited understanding of Photon,
so please take this with some salt.
Hopefully the experts will jump in soon.

I wonder if this hasn’t to do with widgets being “damaged”, so Photon deciding to
redraw.
I’ve had a similar case, where the application was implemented using a lot
of overlapping widgets, and an update function potentially updating
the display every 100ms (e.g. even if nothing changed, it would still do
the setresource/setwidget thingy).
I ended up maintaining my own state of updates/damage, and not relying on
Photon’s states, and the flickering went away.

You may also want to check the sequence of your widgets, if you have
overlap of widgets.
Widgets will be redrawn starting furthest away from the screen
and moving towards you. It may be that a widget deep in is
being changed, and thus causing a redraw all the way to the front.

This all said, I would think that because of its nature RtTrend will cause
a lot of redrawing to happen every time the trend has to be updated.

Have you tried to simplify e.g. what happens .e.g with just RtTrend,
with no other widgets in the application?