Re: DGITAL_MEDIA_PBUFFER and Performer

New Message Reply Date view Thread view Subject view Author view

Software Development & Support. (brainval++at++ehome.encis.es)
Tue, 02 Feb 1999 11:06:36 -0500


Hello All.

These are the different approachs to the problem of combinning:
PERFORMER + O2 VIDEO + ALPHA.

1) make a dual-path connection using the video library:
    screen-to-mem and then mem-to-vid (but you won't get
    any alpha out of this one )

It's true, I've already done, and there is no way to output any alpha,
even if
you open the screen_to_mem with an 5551 config !

PB --> NO ALPHA.

2) Create a normal window and context, create a pbuffer
   with its own context, link it to a dmbuffer with
   glXAssociateDMPbufferSGIX(...), and copy the pixels
   from the frame buffer to the pbuffer (you will then be doing
   two DMA's so it's fast )

We have already tried these option. But it's not fast enought.
First render in Performer, then copy to the PBuffer, and send to the
video path..

PB --> SLOW, We can't achieve Real Time(50/60 Hz).

3) Do an off-screen rendering on your pbuffer, and copy back
   the pixels to the frame buffer.

These is the solution that we are trying now. But there is also many
cases:

A - Let Performer open the PBuffer. And try later to associate with a
dmedia buffer.
PB --> Performer does not set de dmedia buffer property. Then we can not
associate with the
            dmbuffer.

B - Open the Pbuffer with the correct properties and assign it to the
pfPipeWin Drawable.

PB --> On openning these pipeWindow, the program crashes. Saying
something like not enought ressources for
the operation.

C - Let Performer open the PBuffer, draw in these pbuffer, and then
copy the pbuffer to another pbuffer
associated with a dmedia, and send it to the video path.

These solution works, but ...

PB --> SLOW, it's not really real time.

Any help will be apreciated!

We still working on it.

Hector Viguer.

--
Brainstorm Multimedia.
Software  development.

e_mail: brainval++at++ehome.encis.es

Hello All.

These are the different approachs to the problem of combinning:
PERFORMER + O2 VIDEO + ALPHA.

1) make a dual-path connection using the video library:
    screen-to-mem and then mem-to-vid (but you won't get
    any alpha out of this one )

It's true, I've already done, and there is no way to output any alpha, even if
you open the screen_to_mem with an 5551 config !

PB --> NO ALPHA.

2) Create a normal window and context, create a pbuffer
   with its own context, link it to a dmbuffer with
   glXAssociateDMPbufferSGIX(...), and copy the pixels
   from the frame buffer to the pbuffer (you will then be doing
   two DMA's so it's fast )

We have already tried these option. But it's not fast enought.
First render in Performer, then copy to the PBuffer, and send to the video path..

PB --> SLOW, We can't achieve Real Time(50/60 Hz).

3) Do an off-screen rendering on your pbuffer, and copy back
   the pixels to the frame buffer.

These is the solution that we are trying now. But there is also many cases:
 

A - Let Performer open the PBuffer. And try later to associate with a dmedia buffer.
PB --> Performer does not set de dmedia buffer property. Then we can not associate with the
            dmbuffer.

B - Open the Pbuffer with the correct properties and assign it to the pfPipeWin Drawable.

PB --> On openning these pipeWindow, the program crashes. Saying something like not enought ressources for
the operation.

C - Let Performer open the PBuffer,  draw in these pbuffer, and then copy the pbuffer to another pbuffer
associated with a dmedia, and send it to the video path.

These solution works, but ...

PB --> SLOW, it's not really real time.
 
 
Any help will be apreciated!

We still working on it.
 

Hector Viguer.

-- 
Brainstorm Multimedia.  
Software  development.

e_mail: brainval++at++ehome.encis.es
 

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Feb 02 1999 - 02:00:07 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.