PtOSContainer

Hi,

what is the trick that PtOSContainer uses
to blit it’s offscreen context to the screen?

Where and when is the blitting done?
How does a PtContainer widget know
that all of it’s children have been drawn?

TIA
Peter

David Rempel wrote:

PtOSContainer actually draws it’s children itself within it’s draw function, first it
checks to see if it’s been damaged, and if it has been it sets the current DC
to the offscreen context, sets the offscreen translation
with PdSetOffscreenTranslation to pull things back to the origin of the PtOSContainer,
and calls PtDrawClippedWidget which isn’t doc’d, I think it’s one of the functions
that we have for internal use only (it’s internal to the widget engine).
This is exactly what i need for a application i’m working with if I

understand correctly. This allows me to ‘copy’ part of a widget, into a
Ofscreen, and then blit it back. (new cursor code in abiword requires me
to do this)
Lovly, any special reason it’s for ‘internal use only’ or is it safe to
start using it? :slight_smile:
What is the first and the third param?

PtDrawClippedWidget(unsigned int,PtWidget_t *,int,PhRect_t const *)



Once this

function returns it’s safe to blit the contents of the offscreen context to the screen.
PtBlit also has some knowledge of PtOSContainer so that it can operate properly.
Currently it’s a little hacky, but work is being done make it more general and
actually be part of the widget engine instead of the “tricks” that PtOSContainer
uses (plus the ugly notion that PtBlit actually has to know about PtOSContainer
in order to work properly with it). When this work is done PtContainer would have
the option of having a DC other than the default one, and all PtOSContainer would do is
handle the maintenance of the DC (resize, destroy, create) and tell PtContainer which
DC to use (and supply it with a blit function for PtBlit to use).

I can’t exactly tell you when this will appear for GA but I can guess the fall of next year.
Schedules change (since nothings been made official yet) but I doubt it would be before then.

What is it you’re trying to do?

Dave Rempel


“Peter St?ckigt” <> stoeckigt.p@stn-atlas.de> > wrote:

Hi,


what is the trick that PtOSContainer uses
to blit it’s offscreen context to the screen?


Where and when is the blitting done?
How does a PtContainer widget know
that all of it’s children have been drawn?


TIA
Peter


\

/Johan (sorry for jumpin into this post )

PtOSContainer actually draws it’s children itself within it’s draw function, first it
checks to see if it’s been damaged, and if it has been it sets the current DC
to the offscreen context, sets the offscreen translation
with PdSetOffscreenTranslation to pull things back to the origin of the PtOSContainer,
and calls PtDrawClippedWidget which isn’t doc’d, I think it’s one of the functions
that we have for internal use only (it’s internal to the widget engine). Once this
function returns it’s safe to blit the contents of the offscreen context to the screen.
PtBlit also has some knowledge of PtOSContainer so that it can operate properly.
Currently it’s a little hacky, but work is being done make it more general and
actually be part of the widget engine instead of the “tricks” that PtOSContainer
uses (plus the ugly notion that PtBlit actually has to know about PtOSContainer
in order to work properly with it). When this work is done PtContainer would have
the option of having a DC other than the default one, and all PtOSContainer would do is
handle the maintenance of the DC (resize, destroy, create) and tell PtContainer which
DC to use (and supply it with a blit function for PtBlit to use).

I can’t exactly tell you when this will appear for GA but I can guess the fall of next year.
Schedules change (since nothings been made official yet) but I doubt it would be before then.

What is it you’re trying to do?

Dave Rempel


“Peter St?ckigt” <stoeckigt.p@stn-atlas.de> wrote:

Hi,

what is the trick that PtOSContainer uses
to blit it’s offscreen context to the screen?

Where and when is the blitting done?
How does a PtContainer widget know
that all of it’s children have been drawn?

TIA
Peter

Thanks for the detailed explanation.

I just try to learn how things work. I migrate an application with real time
video overlay from
QNX4 to QNX6. Under QNX4 I used offscreen memory from a rage pro, controlled
by the
QNX modeswitcher. I blitted several images together and finally displayed
them in the visible
part of the video memory. This was something like delta framing and had the
advantage that
there is no flickering at all, since not only one application used offscreen
memory, but Photon
at all.

Now I try to find a solution with Photon 2, having real time video overlay
and no flickering in
any other (custom) widgets (mainly gauges). One solution would be
double-buffering at devg*
level, but my app. needs to get called before the buffers are switched. So I
can render my
real-time video.

An other solution would be using the overlay scalar, but it has no source
color keying and does
not support 8bpp palette base images and is therefore not applicable.

A third solution is to have the hole application inside a PtOSContainer and
render the real-time
video to this container (PtGetParent, PgContextBlit) within the draw
function of a child widget.
This is what I actually do and it works so far.

As I said at the beginning, I try to understand what’s going on.

A nice feature would be that two applications can share an offscreen
context, so that one can
render an image at low priority and the other one displays it as described
under third solution.
Even though there are PdLockOffscreen and PdUnlockOffscreen, I don’t know
what for they can
be used. Perhaps together with multiple threads, but I am not sure weather a
Photon application
works well with multiple threads.

Regards
Peter


“David Rempel” <drempel@qnx.com> schrieb im Newsbeitrag
news:aoh9na$3io$1@nntp.qnx.com

PtOSContainer actually draws it’s children itself within it’s draw
function, first it
checks to see if it’s been damaged, and if it has been it sets the current
DC
to the offscreen context, sets the offscreen translation
with PdSetOffscreenTranslation to pull things back to the origin of the
PtOSContainer,
and calls PtDrawClippedWidget which isn’t doc’d, I think it’s one of the
functions
that we have for internal use only (it’s internal to the widget engine).
Once this
function returns it’s safe to blit the contents of the offscreen context
to the screen.
PtBlit also has some knowledge of PtOSContainer so that it can operate
properly.
Currently it’s a little hacky, but work is being done make it more general
and
actually be part of the widget engine instead of the “tricks” that
PtOSContainer
uses (plus the ugly notion that PtBlit actually has to know about
PtOSContainer
in order to work properly with it). When this work is done PtContainer
would have
the option of having a DC other than the default one, and all
PtOSContainer would do is
handle the maintenance of the DC (resize, destroy, create) and tell
PtContainer which
DC to use (and supply it with a blit function for PtBlit to use).

I can’t exactly tell you when this will appear for GA but I can guess the
fall of next year.
Schedules change (since nothings been made official yet) but I doubt it
would be before then.

What is it you’re trying to do?

Dave Rempel


“Peter St?ckigt” <> stoeckigt.p@stn-atlas.de> > wrote:
Hi,

what is the trick that PtOSContainer uses
to blit it’s offscreen context to the screen?

Where and when is the blitting done?
How does a PtContainer widget know
that all of it’s children have been drawn?

TIA
Peter
\

phearbear <phearbear@home.se> wrote:

David Rempel wrote:
PtOSContainer actually draws it’s children itself within it’s draw function, first it
checks to see if it’s been damaged, and if it has been it sets the current DC
to the offscreen context, sets the offscreen translation
with PdSetOffscreenTranslation to pull things back to the origin of the PtOSContainer,
and calls PtDrawClippedWidget which isn’t doc’d, I think it’s one of the functions
that we have for internal use only (it’s internal to the widget engine).
This is exactly what i need for a application i’m working with if I
understand correctly. This allows me to ‘copy’ part of a widget, into a
Ofscreen, and then blit it back. (new cursor code in abiword requires me
to do this)
Lovly, any special reason it’s for ‘internal use only’ or is it safe to
start using it? > :slight_smile:
What is the first and the third param?

PtDrawClippedWidget(unsigned int,PtWidget_t *,int,PhRect_t const *)

PtDrawClippedWidget is likely to change in an upcoming release, I don’t recommend using it.

I haven’t tried this, but it should do what you want with the publicly available API’s:

old_dc = PhDCSetCurrent(offscreen); /* set the offscreen context active /
PtDamageWidget(widget); /
mark the widget heirarchy as damaged so it will draw itself /
PtFlush(); /
do any pending widget draws /
PhDCSetCurrent(old_dc); /
restore the old context */

If you don’t want the entire widget damaged you can use PtDamageExtent() to
damage a portion of the widget.


/Johan (sorry for jumpin into this post )

Dave Rempel (you’re forgiven :stuck_out_tongue_winking_eye: )

“Peter St?ckigt” <stoeckigt.p@stn-atlas.de> wrote:

Thanks for the detailed explanation.

No problem.

A nice feature would be that two applications can share an offscreen
context, so that one can
render an image at low priority and the other one displays it as described
under third solution.
Even though there are PdLockOffscreen and PdUnlockOffscreen, I don’t know
what for they can
be used. Perhaps together with multiple threads, but I am not sure weather a
Photon application
works well with multiple threads.

PdLockOffscreen and PdUnlockOffscreen are there primarily for when you are using
a pointer via PdGetOffscreenContextPtr(), if you’re not using the pointer (which you
aren’t in this case then) you shouldn’t worry about them.

I agree, it would be nice to have a way of allowing multiple processes share the
offscreen context (you can hack the offscreen contexts members to do this already,
but a supported way would be nice). I’ll put it on the TODO list.

Photon threading is pretty basic right now (PtEnter and PtLeave for locking the entire
photon lib), there is some work on going to allow for a little bit more flexability wrt
using photon in a multi-threaded application. Same answer as before for when it’s likely
to appear.

Regards
Peter

Dave Rempel