Hello QNXers,
I wish to continue up the Photon learning curve by progressing from
display of static 2-D gray scale data to display of dynamic
(scrolling) data. The first stage was accomplished by following John
Fehr’s “Who Gives a Blit?” developer article. I shifted my 16-bit
image down to 8 significant bits and copied into a display buffer
(rotating 90-degrees on the way – but that’s not important).
Now I want to collect live conveyor belt data from a line scanning
device which, as the concept now exists, will be placed line-by-line
in a big circular buffer from which the display data is extracted. I
have no problem with managing the circular buffer but I am scratching
my head about the display.
The desired effect is to display a horizontally scrolling image which
reflects the motion of objects on the belt. It seems extremely time
consuming to write an entirely new display buffer after every new line
dumped into the raw data buffer. But, considering the sliding window
of relevant data, the end-of-buffer wraparound and image rotation, I
don’t see an alternative.
Besides creative programming, perhaps the hardware can help: this is
happening on an Advantech SBC (model PCA-6178) which employs an ATI
Rage Pro Turbo display controller.
Hints, tips and tricks deeply appreciated.
Bob Bottemiller
Stein.DSI/Redmond, WA USA
Hey Bob
You can do all of your manipulations inside the offscreen context and then just blit
the new offscreen context to the screen. For example, you blit a line out of your offscreen
context and then replce it on the other side. Then you blit the completly new offscreen
context on to the screen.
Thanks
Rodney
Bob Bottemiller <bob.bottemiller@deletefmcti.com> wrote:
Hello QNXers,
I wish to continue up the Photon learning curve by progressing from
display of static 2-D gray scale data to display of dynamic
(scrolling) data. The first stage was accomplished by following John
Fehr’s “Who Gives a Blit?” developer article. I shifted my 16-bit
image down to 8 significant bits and copied into a display buffer
(rotating 90-degrees on the way – but that’s not important).
Now I want to collect live conveyor belt data from a line scanning
device which, as the concept now exists, will be placed line-by-line
in a big circular buffer from which the display data is extracted. I
have no problem with managing the circular buffer but I am scratching
my head about the display.
The desired effect is to display a horizontally scrolling image which
reflects the motion of objects on the belt. It seems extremely time
consuming to write an entirely new display buffer after every new line
dumped into the raw data buffer. But, considering the sliding window
of relevant data, the end-of-buffer wraparound and image rotation, I
don’t see an alternative.
Besides creative programming, perhaps the hardware can help: this is
happening on an Advantech SBC (model PCA-6178) which employs an ATI
Rage Pro Turbo display controller.
Hints, tips and tricks deeply appreciated.
Bob Bottemiller
Stein.DSI/Redmond, WA USA
On 23 Nov 2001 19:37:51 GMT, Gui Group <gui@qnx.com> wrote:
Hey Bob
You can do all of your manipulations inside the offscreen context and then just blit
the new offscreen context to the screen. For example, you blit a line out of your offscreen
context and then replce it on the other side. Then you blit the completly new offscreen
context on to the screen.
Thanks
Rodney
Thanks for the tip but I am still not altogether clear on this.
Let’s say a new scan line has its data values reformatted to agree
with the intended display mode (e.g. Pg_IMAGE_DIRECT_888) and placed
in a buffer created by PgShmemCreate(). Subsequently, an N-line
section of this buffer is displayed using PgDrawImagemx() and
PgFlush(). OK.
Now the next line arrives and is appended in the buffer and the next
blit is requested to start one line further into memory. This results
in “buffer creep” and, at some point, there needs to be either:
(a) a two-step draw process to compensate for image “wrap-around”
or
(b) a block move of the current image back to the beginning of the
buffer.
Since I don’t understand the “blit a line out of your offscreen
context” part of your explanation, perhaps that is the key to avoiding
the clumsiness of (a) or (b).
Hoping for more advice…
Bob Bottemiller <> bob.bottemiller@deletefmcti.com> > wrote:
Hello QNXers,
I wish to continue up the Photon learning curve by progressing from
display of static 2-D gray scale data to display of dynamic
(scrolling) data. The first stage was accomplished by following John
Fehr’s “Who Gives a Blit?” developer article. I shifted my 16-bit
image down to 8 significant bits and copied into a display buffer
(rotating 90-degrees on the way – but that’s not important).
Now I want to collect live conveyor belt data from a line scanning
device which, as the concept now exists, will be placed line-by-line
in a big circular buffer from which the display data is extracted. I
have no problem with managing the circular buffer but I am scratching
my head about the display.
The desired effect is to display a horizontally scrolling image which
reflects the motion of objects on the belt. It seems extremely time
consuming to write an entirely new display buffer after every new line
dumped into the raw data buffer. But, considering the sliding window
of relevant data, the end-of-buffer wraparound and image rotation, I
don’t see an alternative.
Besides creative programming, perhaps the hardware can help: this is
happening on an Advantech SBC (model PCA-6178) which employs an ATI
Rage Pro Turbo display controller.
Hints, tips and tricks deeply appreciated.
Bob Bottemiller
Stein.DSI/Redmond, WA USA
Bob Bottemiller
Stein.DSI/Redmond, WA USA
Bob Bottemiller <bob.bottemiller@deletefmcti.com> wrote:
On 23 Nov 2001 19:37:51 GMT, Gui Group <> gui@qnx.com> > wrote:
Hey Bob
You can do all of your manipulations inside the offscreen context and then just blit
the new offscreen context to the screen. For example, you blit a line out of your offscreen
context and then replce it on the other side. Then you blit the completly new offscreen
context on to the screen.
Thanks
Rodney
Thanks for the tip but I am still not altogether clear on this.
Let’s say a new scan line has its data values reformatted to agree
with the intended display mode (e.g. Pg_IMAGE_DIRECT_888) and placed
in a buffer created by PgShmemCreate(). Subsequently, an N-line
section of this buffer is displayed using PgDrawImagemx() and
PgFlush(). OK.
Now the next line arrives and is appended in the buffer and the next
blit is requested to start one line further into memory. This results
in “buffer creep” and, at some point, there needs to be either:
(a) a two-step draw process to compensate for image “wrap-around”
or
(b) a block move of the current image back to the beginning of the
buffer.
Since I don’t understand the “blit a line out of your offscreen
context” part of your explanation, perhaps that is the key to avoiding
the clumsiness of (a) or (b).
Hoping for more advice…
Hey Bob
What I meant was this. You have a final image that you want to display
on your screen. This final image is in your offscreen context. You
can perform manipulations on that offscreen context ( such as blitting )
as if it were on the screen. I’m assuming that you have data coming in
that you wish to represent on the screen and that you have data moving
out that you no longer need to display. When new data comes in, lets
say 2 new images that represent 6 pixels, you shift the old data out of
you offscreen context, 6 pixels worth, first by blitting your offscreen
context over by 6 pixels. You then draw the new data that you have
recieved at the end of your offscreen context. So now your new data
is in place. You blit the whole offscreen context on to your screen to
the area where you want this data to be and you are free to start the
whole process over again. If I’m simplifying the problem too much then
please point out where I have made my misunderstanding of the situation.
Thanks
Rodney
Bob Bottemiller <> bob.bottemiller@deletefmcti.com> > wrote:
Hello QNXers,
I wish to continue up the Photon learning curve by progressing from
display of static 2-D gray scale data to display of dynamic
(scrolling) data. The first stage was accomplished by following John
Fehr’s “Who Gives a Blit?” developer article. I shifted my 16-bit
image down to 8 significant bits and copied into a display buffer
(rotating 90-degrees on the way – but that’s not important).
Now I want to collect live conveyor belt data from a line scanning
device which, as the concept now exists, will be placed line-by-line
in a big circular buffer from which the display data is extracted. I
have no problem with managing the circular buffer but I am scratching
my head about the display.
The desired effect is to display a horizontally scrolling image which
reflects the motion of objects on the belt. It seems extremely time
consuming to write an entirely new display buffer after every new line
dumped into the raw data buffer. But, considering the sliding window
of relevant data, the end-of-buffer wraparound and image rotation, I
don’t see an alternative.
Besides creative programming, perhaps the hardware can help: this is
happening on an Advantech SBC (model PCA-6178) which employs an ATI
Rage Pro Turbo display controller.
Hints, tips and tricks deeply appreciated.
Bob Bottemiller
Stein.DSI/Redmond, WA USA
Bob Bottemiller
Stein.DSI/Redmond, WA USA
Hello Rodney,
Thanks for the follow-up response. The light bulb above my head is
slowly getting brighter. I have one last (I promise) comment and
question… see below after your last offering
On 28 Nov 2001 16:33:03 GMT, Gui Group <gui@qnx.com> wrote:
Bob Bottemiller <> bob.bottemiller@deletefmcti.com> > wrote:
On 23 Nov 2001 19:37:51 GMT, Gui Group <> gui@qnx.com> > wrote:
Hey Bob
You can do all of your manipulations inside the offscreen context and then just blit
the new offscreen context to the screen. For example, you blit a line out of your offscreen
context and then replce it on the other side. Then you blit the completly new offscreen
context on to the screen.
Thanks
Rodney
Thanks for the tip but I am still not altogether clear on this.
[clip]
Hey Bob
What I meant was this. You have a final image that you want to display
on your screen. This final image is in your offscreen context. You
can perform manipulations on that offscreen context ( such as blitting )
as if it were on the screen. I’m assuming that you have data coming in
that you wish to represent on the screen and that you have data moving
out that you no longer need to display. When new data comes in, lets
say 2 new images that represent 6 pixels, you shift the old data out of
you offscreen context, 6 pixels worth, first by blitting your offscreen
context over by 6 pixels. You then draw the new data that you have
recieved at the end of your offscreen context. So now your new data
is in place. You blit the whole offscreen context on to your screen to
the area where you want this data to be and you are free to start the
whole process over again. If I’m simplifying the problem too much then
please point out where I have made my misunderstanding of the situation.
Thanks
Rodney
Here goes: you have described exactly what I thought you meant. My
remaining confusion is over “blitting” to accomplish the sliding,
offscreen image Up to now I have used a shared memory region to
prepare the display pixels then do one blit into video memory using
PgDrawImagemx.
But you describe the offscreen preparation phase as using blit
operations. Does that mean I use a region of video memory instead of
shared processor RAM to cast off the old strips, slide the remainder
and paste in the new data? In other words, use
PdCreateOffscreenContext, PdGetOffscreenContextPtr, PgContextBlit,
etc. as described in John Fehr’s “Method 3” of “Who Gives a Blit?”
Thanks Again,
Bob Bottemiller
Stein.DSI/Redmond, WA USA