PgDrawImage

QNX Newsgroups (Archives) qnx.gui
1

I grab frames from a frame grabber and display them on a Photon Window using
PgDrawImage. Each pixel is represented by a byte and so I use
Pg_IMAGE_RADIENT_BYTE as the type. When I run this application, I dont’ see
any image. However, If I click on the Frame Window or click another button,
it displays the frames.

Your suggestions are appreciated.

Thanks

Shashank

2

Shashank <sbalijepalli@precitech.com> wrote:

I grab frames from a frame grabber and display them on a Photon Window using
PgDrawImage. Each pixel is represented by a byte and so I use
Pg_IMAGE_RADIENT_BYTE as the type. When I run this application, I dont’ see
any image. However, If I click on the Frame Window or click another button,
it displays the frames.

If you’re going to use Pg functions, you need to create a PtRaw widget
and do your drawing in its Draw function. See the Raw Drawing and Animation
chapter of the Photon Programmer’s Guide.

Steve Reid stever@qnx.com
Technical Editor
QNX Software Systems

3

Hello, Shashank!

S> Your suggestions are appreciated.

PgFlush();

With best regards, Mike Gorchak. E-mail: mike@malva.com.ua

4

Thanks Mike & Steve. But I am still having a problem displaying frames.

I am now using a PtRaw Widget and use PgFlush as well.

Basically, I am grabbing frames from a frame grabber and displaying them on
the Raw Widget. I have a callback that is invoked by a timer every 30m sec
that damages the raw widget and my PtRaw draw function draws the frame on
the raw widget. If I do this, the frames keep blinking and my application
hangs up.

If I directly call the function that draws the frame on the raw widget from
my timer callback, then it display the frames after I click another button
and is unpredictable.

Thanks

Shashank






“Mike Gorchak” <mike@malva.com.ua> wrote in message
news:de12t5$l8t$1@inn.qnx.com…

Hello, Shashank!

S> Your suggestions are appreciated.

PgFlush();

With best regards, Mike Gorchak. E-mail: > mike@malva.com.ua

5

Hello

Shashank wrote:

Thanks Mike & Steve. But I am still having a problem displaying frames.

I am now using a PtRaw Widget and use PgFlush as well.

Basically, I am grabbing frames from a frame grabber and displaying them on
the Raw Widget. I have a callback that is invoked by a timer every 30m sec
that damages the raw widget and my PtRaw draw function draws the frame on
the raw widget. If I do this, the frames keep blinking and my application
hangs up.

How big are the frames that you have to draw? Can you draw the frame
and make it back to the mainloop before your timer goes off again? Can
you post your raw draw callback and the timer callback? Also have you
thought about setting up an offscreen context and just blitting that
your raw widget?

If I directly call the function that draws the frame on the raw widget from
my timer callback, then it display the frames after I click another button
and is unpredictable.

Probably not a good idea to call the function directly because it may
assume that certain things such as clipping have been initialized for
you. If you want to invoke your draw function then call PtDamageWidget.

Thanks,
Rodney

Thanks

Shashank






“Mike Gorchak” <> mike@malva.com.ua> > wrote in message
news:de12t5$l8t$> 1@inn.qnx.com> …

Hello, Shashank!

S> Your suggestions are appreciated.

PgFlush();

With best regards, Mike Gorchak. E-mail: > mike@malva.com.ua

\

6

My frames are 640*480 . Maybe the mainloop in invoked at a faster rate than
the rate at which I am being able to draw frames on the raw widget. I know
the frame grabber can grab frames at a rate of 30 msec. Do you think
increasing the interval rate of the timer might help.

How do I set up an offscreen context?

Thanks
Shashank

“Rodney Dowdall” <rdowdall@qnx.com> wrote in message
news:de2gpk$ohe$1@inn.qnx.com…

Hello

Shashank wrote:
Thanks Mike & Steve. But I am still having a problem displaying frames.

I am now using a PtRaw Widget and use PgFlush as well.

Basically, I am grabbing frames from a frame grabber and displaying them
on
the Raw Widget. I have a callback that is invoked by a timer every 30m
sec
that damages the raw widget and my PtRaw draw function draws the frame
on
the raw widget. If I do this, the frames keep blinking and my
application
hangs up.

How big are the frames that you have to draw? Can you draw the frame
and make it back to the mainloop before your timer goes off again? Can
you post your raw draw callback and the timer callback? Also have you
thought about setting up an offscreen context and just blitting that
your raw widget?


If I directly call the function that draws the frame on the raw widget
from
my timer callback, then it display the frames after I click another
button
and is unpredictable.

Probably not a good idea to call the function directly because it may
assume that certain things such as clipping have been initialized for
you. If you want to invoke your draw function then call PtDamageWidget.

Thanks,
Rodney


Thanks

Shashank






“Mike Gorchak” <> mike@malva.com.ua> > wrote in message
news:de12t5$l8t$> 1@inn.qnx.com> …

Hello, Shashank!

S> Your suggestions are appreciated.

PgFlush();

With best regards, Mike Gorchak. E-mail: > mike@malva.com.ua

\

7

There are two main reasons we recommend using a PtRaw widget rather than
calling Pg draw functions directly from a callback:

  • Because it’s simpler. For a Pg draw call to work, you must set up
    your context first: the region to draw from, the translation, several
    types of clipping, and so on. And afterwards, you must remember to
    flush. If you put your drawing code in a PtRaw widget, the library will
    take care of all those details for you.

  • Because it ensures that your draw function is called whenever the
    widget needs to be drawn for whatever reason. If you draw only when
    you decide that a new image needs to be drawn, you will not redraw the
    old image when your window gets clobbered by a console switch or by
    some other window being dragged in front of yours.

But in your case, I don’t think you actually want to draw the old frame
again when your window gets an expose event. Drawing the same frame
twice takes too much time. Instead, you want to wait for the next time.
You know that it’s coming up within the next 30ms.

A simple way to solve this without losing the benefits of the raw widget
is by having a global flag that you set when you get a new frame, and
clear when you draw the frame. If the flag is already unset when your
draw function runs, you’ll know that you don’t have a new frame to draw,
and just return.

Shashank wrote:

Thanks Mike & Steve. But I am still having a problem displaying frames.

I am now using a PtRaw Widget and use PgFlush as well.

Basically, I am grabbing frames from a frame grabber and displaying them on
the Raw Widget. I have a callback that is invoked by a timer every 30m sec
that damages the raw widget and my PtRaw draw function draws the frame on
the raw widget. If I do this, the frames keep blinking and my application
hangs up.

Does your raw widget have its fill colour set to anything
non-transparent? Unless the library believes that your widget is a
solid opaque rectangle, it’ll make the widget behind you draw first. I
bet that’s where the flicker is coming from. To check that, you can set
the raw widget’s parent to a contrasting fill colour, like yellow or
neon green.

What state is your application in when it hangs up?

If I directly call the function that draws the frame on the raw widget from
my timer callback, then it display the frames after I click another button
and is unpredictable.

That’s because the region and clipping and maybe some other context
settings reflect whatever widget drew last. You need to either set up
all those things before you draw, or let the widget library set it up
for you.

8

Shashank wrote:

Thanks Mike & Steve. But I am still having a problem displaying frames.

I am now using a PtRaw Widget and use PgFlush as well.

I don’t think it’s a good idea to flush inside the widgets draw function. It’s either or. Either you use PgFlush in the old code or use a PtRaw widget without PgFlush.

Actually, it sounds more like you are wanting an off-screen context.


Evan

9

I got the thing to work correctly by using Pg_IMAGE_DIRECT_888 in the type
argument of PgDrawImage. However, I don’t want colored frames, so I tried
using Pg_IMAGE_PALETTE_BYTE and Pg_IMAGE_GRADIENT_BYTE. Neither works and i
get a blank screen.

I guess I am not setting the pallete correctly. But I dont know what I can
do to display gray scale frames.

Any suggestions?

Thanks

Shashank




“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:de2prd$1m3$1@inn.qnx.com…

Shashank wrote:
Thanks Mike & Steve. But I am still having a problem displaying frames.

I am now using a PtRaw Widget and use PgFlush as well.


I don’t think it’s a good idea to flush inside the widgets draw function.
It’s either or. Either you use PgFlush in the old code or use a PtRaw

widget without PgFlush.

Actually, it sounds more like you are wanting an off-screen context.


Evan

10

I would really appreciate it if someone could help me with this.

Thanks
Shashank


“Shashank” <sbalijepalli@precitech.com> wrote in message
news:de4tk8$hg8$7@inn.qnx.com…

I got the thing to work correctly by using Pg_IMAGE_DIRECT_888 in the type
argument of PgDrawImage. However, I don’t want colored frames, so I tried
using Pg_IMAGE_PALETTE_BYTE and Pg_IMAGE_GRADIENT_BYTE. Neither works and
i
get a blank screen.

I guess I am not setting the pallete correctly. But I dont know what I can
do to display gray scale frames.

Any suggestions?

Thanks

Shashank




“Evan Hillas” <> evanh@clear.net.nz> > wrote in message
news:de2prd$1m3$> 1@inn.qnx.com> …
Shashank wrote:
Thanks Mike & Steve. But I am still having a problem displaying
frames.

I am now using a PtRaw Widget and use PgFlush as well.


I don’t think it’s a good idea to flush inside the widgets draw
function.
It’s either or. Either you use PgFlush in the old code or use a PtRaw
widget without PgFlush.

Actually, it sounds more like you are wanting an off-screen context.


Evan

11

Shashank wrote:

I would really appreciate it if someone could help me with this.

Sorry, I never got very far myself, ended in a similar situation to what you are describing - random crashes, wrong graphics being updated, library calls not giving desired results. I haven’t even looked at the 6.3.0 docs for Photon.


Evan

12

Well, how are you setting the palette? You should be using
PgSetPalette() for palette-based images, and PgSetTextColor() and
PgSetFillColor() for gradient images. Is that what you’re doing?

Shashank wrote:

I would really appreciate it if someone could help me with this.

Thanks
Shashank


“Shashank” <> sbalijepalli@precitech.com> > wrote in message
news:de4tk8$hg8$> 7@inn.qnx.com> …

I got the thing to work correctly by using Pg_IMAGE_DIRECT_888 in the type
argument of PgDrawImage. However, I don’t want colored frames, so I tried
using Pg_IMAGE_PALETTE_BYTE and Pg_IMAGE_GRADIENT_BYTE. Neither works and

i

get a blank screen.

I guess I am not setting the pallete correctly. But I dont know what I can
do to display gray scale frames.

Any suggestions?

Thanks

Shashank




“Evan Hillas” <> evanh@clear.net.nz> > wrote in message
news:de2prd$1m3$> 1@inn.qnx.com> …

Shashank wrote:

Thanks Mike & Steve. But I am still having a problem displaying

frames.

I am now using a PtRaw Widget and use PgFlush as well.


I don’t think it’s a good idea to flush inside the widgets draw

function.

It’s either or. Either you use PgFlush in the old code or use a PtRaw
widget without PgFlush.

Actually, it sounds more like you are wanting an off-screen context.


Evan
\

13

On Fri, 19 Aug 2005 15:32:09 -0400, Shashank wrote:

I would really appreciate it if someone could help me with this.

Hhm, I probably did the same like you, but I didn’t have any problems.

Can you post pieces of your source code, specially the
‘drawing’-function of your Raw-Widget?

I also used a PtRaw-Widget, with a call of PgDrawPhImagemx () in the draw
function (works with QNX6.2 and QNX6.3). AFAIR it was mandantory, the
the image has to be in the shared memory, but I’m not sure.

Here’s a piece of my source (the mutex-stuff is, because the grabber is
is handled in another thread):


//------------------------------------------------- draw_function()
void draw_function ( PtWidget_t * widget,
PhTile_t * damage )
{

if ( measure )
StopWatchStart ( );

pthread_mutex_lock ( &image_mutex );

// Do our drawing…
PgDrawPhImagemx ( &image_pos, image, 0 );

pthread_mutex_unlock ( &image_mutex );

if ( measure )
StopWatchStop ( “PgDrawImagemx” );

}


//------------------------------------------ image_widget_create()
void image_widget_create ( PtWidget_t * parent )
{
PhPoint_t origin = { 0, 0 };
PtArg_t wargs[20];
int wargc = 0;

pthread_mutex_lock ( &image_mutex );

if ( image_widget )
PtDestroyWidget ( image_widget );

/*
** Create a ‘Raw’-Widget for drawing purposes.
*/
wargc = 0;
PtSetArg ( &wargs[wargc++], Pt_ARG_POS, &origin, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_DIM, &image->size, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_RAW_DRAW_F, &draw_function, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_BORDER_WIDTH, 0, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_FLAGS, Pt_FALSE, Pt_TRUE );

image_widget = PtCreateWidget ( PtRaw, parent, wargc, wargs );

if ( image_widget )
PtRealizeWidget ( image_widget );

pthread_mutex_unlock ( &image_mutex );
}

HTH,
Karsten.

\

Karsten P. Hoffmann <karsten.p.hoffmann@web.de>
“I love deadlines. I especially like the whooshing sound
they make as they go flying by.”
[In memoriam Douglas Adams, 1952-2001]

14

I got the thing to work for gray scale frames as well. I am running this
application at a priority of 13 and displaying (640*480) frames every 30
msec. However, if i do some image processing, it becomes really slow and if
I give any kind of hardware input, it reacts really slowly. I tried to
display frames every 90msec instead of every 30 msec. But it didn’t make
much of a difference. Is there a way I can improve this?

I appreciate your suugestions.

Shashank


…


“Karsten P. Hoffmann” <karsten.p.hoffmann@web.de> wrote in message
news:pan.2005.08.22.21.50.55.963304@web.de…

On Fri, 19 Aug 2005 15:32:09 -0400, Shashank wrote:
I would really appreciate it if someone could help me with this.

Hhm, I probably did the same like you, but I didn’t have any problems.

Can you post pieces of your source code, specially the
‘drawing’-function of your Raw-Widget?

I also used a PtRaw-Widget, with a call of PgDrawPhImagemx () in the draw
function (works with QNX6.2 and QNX6.3). AFAIR it was mandantory, the
the image has to be in the shared memory, but I’m not sure.

Here’s a piece of my source (the mutex-stuff is, because the grabber is
is handled in another thread):


//------------------------------------------------- draw_function()
void draw_function ( PtWidget_t * widget,
PhTile_t * damage )
{

if ( measure )
StopWatchStart ( );

pthread_mutex_lock ( &image_mutex );

// Do our drawing…
PgDrawPhImagemx ( &image_pos, image, 0 );

pthread_mutex_unlock ( &image_mutex );

if ( measure )
StopWatchStop ( “PgDrawImagemx” );

}


//------------------------------------------ image_widget_create()
void image_widget_create ( PtWidget_t * parent )
{
PhPoint_t origin = { 0, 0 };
PtArg_t wargs[20];
int wargc = 0;

pthread_mutex_lock ( &image_mutex );

if ( image_widget )
PtDestroyWidget ( image_widget );

/*
** Create a ‘Raw’-Widget for drawing purposes.
*/
wargc = 0;
PtSetArg ( &wargs[wargc++], Pt_ARG_POS, &origin, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_DIM, &image->size, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_RAW_DRAW_F, &draw_function, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_BORDER_WIDTH, 0, 0 );
PtSetArg ( &wargs[wargc++], Pt_ARG_FLAGS, Pt_FALSE, Pt_TRUE );

image_widget = PtCreateWidget ( PtRaw, parent, wargc, wargs );

if ( image_widget )
PtRealizeWidget ( image_widget );

pthread_mutex_unlock ( &image_mutex );
}

HTH,
Karsten.

\

Karsten P. Hoffmann <> karsten.p.hoffmann@web.de
“I love deadlines. I especially like the whooshing sound
they make as they go flying by.”
[In memoriam Douglas Adams, 1952-2001]