[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



I have no idea why an opengl surface save is handled in such a convoluted way. But it made me try blitting an opengl surface to a software surface.


import pygame, unittest, os, test_utils
from pygame.locals import *

screen = pygame.display.set_mode((640,480), OPENGL|DOUBLEBUF)
pygame.display.flip()
surf = pygame.Surface(screen.get_size(),
                     SWSURFACE,
                     screen.get_bitsize())
surf.blit(screen, (0, 0))


It also segfaults. The blit trys to do what is suggested, directly copy the opengl SDL surface's pixels.

Lenard


Brian Fisher wrote:
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 <mailto: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>
        <mailto: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.