[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[pygame] Double Buffered display vs Overlays
- To: pygame-users@xxxxxxxx
- Subject: [pygame] Double Buffered display vs Overlays
- From: Michael Sparks <zathras@xxxxxxxxxxxxx>
- Date: Thu, 15 Sep 2005 20:28:05 +0100
- Delivered-to: archiver@seul.org
- Delivered-to: pygame-users-outgoing@seul.org
- Delivered-to: pygame-users@seul.org
- Delivery-date: Thu, 15 Sep 2005 15:28:05 -0400
- Organization: Mug of tea and a couple of biccies
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
- User-agent: KMail/1.8
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.