what is the trick that PtOSContainer

源： http://www.openqnx.com/newsgroups/viewtopic.php?f=14&t=15628

---

Postby Peter Stöckigt » Fri Oct 11, 2002 9:57 am

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?

---

Postby David Rempel » Tue Oct 15, 2002 2:46 pm

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(draw_context) 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

---

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

---

understand correctly. This allows me to ‘copy’ part of a widget, into a offscreen, 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? :)
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.

---

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