Re: gl, image.save crash... was (Re: [pygame] Automated Builds)

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

I get what the new code is trying to do - but my point was that at some point a surface is written out to a file - I was specifically asking how that is accomplished, possibly deep in SDL land. If SDL was able to lock the GL display surface, and get a * to the pixels, then wouldn't you be able to treat saving the screen exactly the same as all other surfaces?

what happens when you try to save a HWSURFACE DOUBLEBUF display surface and you're not in GL mode, for instance? Why is GL any different at all?

On Tue, Jun 10, 2008 at 8:19 PM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:

No, it only retrieves the display surface to get the size. It creates a new SDL surface, retieves a copy of the display using an opengl routine, then copies this to the surface. The surface is then written out to the file.

Lenard.


Brian Fisher wrote:

I assume the save routine locks the display surface, and then uses the buffer from the lock, yeah? so if locking an opengl display surface worked, then wouldn't save work too?

On Tue, Jun 10, 2008 at 4:25 PM, Lenard Lindstrom <len-l@xxxxxxxxx <mailto:len-l@xxxxxxxxx>> wrote:

   Current (lack of) progress report. All I can determine for sure is
   that setting the screen mode to OPENGL causes pygame.image.save to
   segfault. It doesn't matter what file extension the output file
   has. I have been unable to pin down the exact point where this
   happens since commenting out code moves the location of the
   segfault. Replacing the opengltosdl call with a simple
   SDL_CreateRGBSurface call also segfaults. Two locations where
   sefaults happen are when opengltosdl returns and the
   PyObject_CallObject call to save_extended in imageext. I will play
   around with it some more later. I will also try gdb again. Maybe
   the problem is in set_mode itself. I will have a look at it as well.