Double Buffered display vs Overlays

Hi,


I'm currently decoding and displaying video in a pygame overlay. I also
have a bunch of surfaces I regularly blit into the display surface.

If I render all the surfaces first, and the force the overlay to display,
then any surfaces overlapping the overlay area are rendered behind the
overlay. This is pretty much what you'd expect, and this doesn't have any
issues. (eg no flickering, does what you expect, etc)

If however I render the overlay first, and then all the surfaces, then if
any of the surfaces overlap the display surfaces. This works as you'd
expect - the surfaces are visible over the video. (And keying also works,
which allows an element of live titling for example)

However, even with a double buffered display surface this flickers, which
isn't very pleasant.

This leads me to my questions:
   * This strikes me as potentially a problem in SDL rather than PyGame.
     Does anyone know of a way of making this work without flickering? 

   * Am I doing something really dumb? :-)

   * The older pygame.movie interface has the option to use an arbitrary
      surface instead. Short of me implementing a method to convert IYUV
      data and manually fill a surface with RGB data, am I missing a trick
      in pygame that will do this for me?
      * Would, for example, does anyone know if pygame.movie's mpeg handling
         can handle mpeg YUV ?

Versions:
   * pygame 1.7.1release (pygame-1.7.1release.tar.gz)
   * python 2.4 (Hmm... SuSE 9.3 shipped with 2.4 alpha3 ...)

The actual code I'm talking about here is the code here:

Non-Flickery - surfaces behind overlay:
http://cvs.sourceforge.net/viewcvs.py/kamaelia/Code/Python/Kamaelia/Kamaelia/UI/PygameDisplay.py?rev=1.11&view=auto

Flickery - surfaces in front of overlay:
http://cvs.sourceforge.net/viewcvs.py/kamaelia/Code/Python/Kamaelia/Kamaelia/UI/PygameDisplay.py?rev=1.13&view=auto

Specific class/method: PygameDisplay.updateDisplay

In case it's not clear, the section:
      # now update overlays
      for theoverlay in self.overlays:

has simply been lifted and shifted wholesale before the block starting:
      for surface, position, callbackcomms, eventcomms in self.surfaces:
         display.blit(surface, position)

We've seen some other oddities as well with overlays, so I wouldn't
be suprised if the answers here are negative, but any comments
welcome :)

In case it's of interest/means something to people the video we're decoding
and displaying is Dirac :) (if it doesn't, it's really the explanation for
not using the pygame.movie stuff)

Thanks in advance for any comments/thoughts/ideas,

Regards,


Michael.