Re: [pygame] Double Buffered display vs Overlays

[Michael Sparks <zathras@xxxxxxxxxxxxx>]

On Saturday 17 September 2005 11:25, Michael Sparks wrote:
> On Saturday 17 September 2005 06:49, Pete Shinners wrote:
> > On Fri, 2005-09-16 at 20:29 +0100, Michael Sparks wrote:
> > > Out of interest can a movie object take raw YUV frames in the same sort
> > > of way the Overlay buffer can?
> >
> > Pygame has an Overlay class, but it's a but experimental.
>
> I suppose I wasn't clear enough. We are using Pygame overlays, and finding
> it works very nicely for playback of video, even on unaccelerated displays.
> If that's all you want it's fine :-)
>
> You can dump raw YUV data into it and it works very nicely. It does however
> have 2 minor issues as far as we're concerned:
>
>   1. If you draw surfaces over vdeo overlay, the display flickers. The
>      overlay is drawn & rendered, then anything you draw is rendered over
> it. This process is visible, and hence flickers if you render surfaces over
> video in an overlay. (If the surfaces & video overlap, but the video is in
> front, this doesn't flicker)
>
>      If this sort of thing simply hasn't had much exercise, no problem,
> I'll dig around and see if overlays can be rendered off screen. (There seem
> to be a few options in SDL that aren't in the pygame interface)

I've done a bit of digging around, and it looks like smpeg has this code:
// From: smpeg-0.4.4/video/MPEGvideo.cpp
bool
MPEGvideo:: SetDisplay(SDL_Surface *dst, SDL_mutex *lock,
                             MPEG_DisplayCallback callback)
{
...
    _image = SDL_CreateYUVOverlay(_srcrect.w, _srcrect.h, SDL_YV12_OVERLAY, 
dst);
....

Which specifically is how that creates the overlay. It specifically targets an 
SDL surface, which could therefore be any surface, and is presumably why 
pygame.movie can target an offscreen surface.

This is compared to:

# From: pygame-1.7.1release/src/overlay.c
PyObject* Overlay_New(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
        int pixelformat;
        PyGameOverlay *self;
        int w, h;
        SDL_Surface *screen;
        if(!PyArg_ParseTuple(args, "i(ii)", &pixelformat, &w, &h))
...
        screen = SDL_GetVideoSurface();
        // Create layer with desired format
        self->cOverlay = SDL_CreateYUVOverlay(w, h, pixelformat, screen);

It strikes me that this has the potential to be modified to take a surface as 
an extra argument, and to use that instead of the screen if provided. 

I've only written python extensions via pyrex before, but I think I'll try and 
give this a go since that would be a nice generic solution.

Regards,


Michael.