Why these codes couldn't create a hiden window

def createOffscreenBuffer(sort, xsize, ysize): 
    winprops = WindowProperties.size(xsize,ysize) 
    props = FrameBufferProperties() 
    props.setRgbColor(1) 
    props.setAlphaBits(1) 
    props.setDepthBits(1) 
    """return base.graphicsEngine.makeOutput( 
        base.pipe, "offscreenBuffer", 
        sort, props, winprops, 
        GraphicsPipe.BFFbPropsOptional | GraphicsPipe.BFRefuseWindow)
    """
    return base.graphicsEngine.makeOutput( 
        base.pipe, "offscreenBuffer", 
        sort, props, winprops, 
        GraphicsPipe.BFFbPropsOptional | GraphicsPipe.BFRefuseWindow, 
        base.win.getGsg(), base.win) 
    
class Container(DirectObject): 
    def __init__(self, wxApp): 
        self.wxApp = wxApp 
        self.InitScene() 
        taskMgr.add(self.taskWalk, "walk")

    def InitScene(self): 
        self.buffer = createOffscreenBuffer(0, MODEL_WIDTH, MODEL_HEIGHT) 
        self.LoadModel() 
        self.SetupTexture() 

        # remove the window will also stop the offscreen buffer to come up, 
        # because the gsg is shared ? 
        #base.userExit = lambda: None 
        #base.graphicsEngine.removeWindow(base.win) 

        # minimize is not implemented in panda 
        #props = WindowProperties() 
        #props.setMinimized(True) 
        #base.win.requestProperties(props) 

    def SetupTexture(self): 
        self.screenTexture = Texture() 
        self.screenTexture.setMinfilter(Texture.FTLinear) 
        self.screenTexture.setFormat(Texture.FRgba32) 
        self.buffer.addRenderTexture(self.screenTexture, GraphicsOutput.RTMCopyRam) 
        self.screenImage = PNMImage() 

    def GetImage(self): 
        if self.screenTexture.hasRamImage(): 
            self.screenTexture.store(self.screenImage) 
            screenData = StringStream() 
            #self.screenImage.write(Filename("a.bmp")) 
            self.screenImage.write(screenData, "ppm") 
            return screenData 
        return None 

    def LoadModel(self): 
        self.buffer.setClearColor(VBase4(1.0,0.0,0.0,0.0)) 
        self.cam = base.makeCamera(self.buffer) 
        self.render = NodePath("render") 
        self.cam.reparentTo(self.render) 																
        self.cam.node().setScene(self.render) 														

        self.actor= Actor('panda.egg', {'walk' : 'panda-walk.egg'}) 
        self.actor.setScale(0.15,0.15,0.15) 
        self.actor.reparentTo(self.render) 																
        self.actor.loop("walk") 
        self.cam.lookAt(self.actor.getPos()) 
        self.cam.setPos(0, -5, 0.5) 

        dlight = NodePath(DirectionalLight('dlight')) 
        dlight.reparentTo(self.cam) 
        #dlight.reparentTo(self.render) 
        self.render.setLight(dlight)              

    def taskWalk(self, task):
        self.actor.setX(self.actor, 0.2)
        return task.cont

This pieces of codes is from clcheung. On his computer ,the panda window is unshown. but on my computer ,the window is shown.
And I read the content in manual about “Creating Windows and Buffers”, I also think creating a hiden window should coding like that. But uneffect.

Anyone can help me?

hi,

A small correction here. The panda window is not hidden. I am saying that it can be minimized and after minimize it, the offscreen texture can still be retrieved correctly (unlike the first example).

But on my computer, when minimized the panda window ,the offscreen texture cann’t be retrieved correctly. The wx window’s panda doesn’t walk.

Headache, I have researched it for hours.

BTW, what is your OS, video card hardware, and running on DirectX or OpenGL ?

WinXP \ OpenGL \ Intel® 82945G Express Chipset Family

I don’t think this matter is relatived with video card

Well, I am also new to panda. I am not sure as well.
On my PC, I have to tell panda to not using parasite buffer as state in the source code.

loadPrcFileData("", “prefer-parasite-buffer #f”)

Otherwise it will use a parasite buffer, I believe it mean that it shares with the window video memory. I guess, if your video card memory is not “sufficient”, may be it has created a parasite ?

Add one line to the sample code like this:

    def InitScene(self):
        self.buffer = createOffscreenBuffer(0, MODEL_WIDTH, MODEL_HEIGHT)
        print "Is parasite ?", isinstance(self.buffer, ParasiteBuffer)

Check if it print true or false. If true, it means that a parasite is created, it won’t work.

You are modest.
I am newer to panda.

Yes, it prints “True”. WAHAHAHA, find the problem at last.
You are good.

But how to deal with it? Noway to do in this situation?

I don’t think your hardware supports parasite buffers which is why you’re seeing that behaviour while clcheung gets a different behaviour on his. I think clcheung has given the correct diagnosis on this problem in the other thread, you can’t just create offscreen buffers without the main main window and the offscreen window type seems to be broken. I’ve also come across these limitations in my earlier experiments although they don’t seem to have been resolved yet.

I have no idea and not sure if I am right about this parasite thing. Let’s wait for the experts to get an answer here.

I hope that they can have the makeGsg and window-type offscreen fixed in the coming release.

I concur–for whatever reason, wzj’s drivers do not support a genuine offscreen buffer, and he is constrained to using a ParasiteBuffer, which requires having the main window visible at all times. The Intel 945G is a very popular integrated graphics card, but it is also very limited in its capabilities, so it does not entirely surprise me that it cannot support true offscreen rendering.

There is a different problem with window-type offscreen. For some reason, the ShowBase code doesn’t handle this setting properly. I’ll take a look into it. (Note that window-type offscreen has never worked with DirectX, since our pandadx drivers do not support creating a GSG without having a window. However, it should work fine in OpenGL.)

David

Addendum: window-type offscreen appears to work correctly on the cvs trunk, so consider this fixed for 1.6.0. Also, the tinydisplay software renderer, available in 1.6.0, will solve this offscreen-buffer problem for limited graphics cards such as the 945G, as long as you don’t mind using software rendering (which is not really so bad).

David

Also, in the case of OpenGL, this might have been because there were bugs in the FBO code - I’ve recently fixed these on the 1.6.0 cvs, so it’s very well possible that it will work with the next release.

(This is especially the case for Linux and OSX, but also for Windows.)

OK. Thank you all very much.

Do you mean if I download the source from CVS and compile it ,then all problems can be resolved?

You could give it a try.

David

Is that so? Hee hee.

I’ve been investigating why “window-type offscreen” was broken on Unix/GLX. I made some… interesting discoveries.
First of all, the GLX pipe attempts an FBO. Gets rejected immediately though, because there’s no host window. Then it resorts to a glxPbuffer. Or does it?

  // Third thing to try: a glxGraphicsBuffer
  
  if (retry == 2) {
    if (!glx_support_pbuffer) {
      return NULL;
    }

Looks great. Yup, that’s your code, from about 11 months ago, just before the 1.6.0 release. So is this:

ConfigVariableBool glx_support_pbuffer
("glx-support-pbuffer", false,
 PRC_DESC("Set this true to enable the use of X pbuffer-based offscreen "
          "buffers, if available.  This is usually preferred over "
          "pixmap-based buffers, but not all drivers support them."));

Ah-ha! See the bug? If the default for that variable is ‘false’, pbuffers are always refused unless that cvar is set.
Is there any reason why pbuffers are rejected by default? They serve as fall-back anyways, so why are they disabled?

Oops.

I remember I disabled pbuffers by default because I came across a Linux machine whose driver claimed to support pbuffers, but the machine kernel panicked (!) whenever you attempted to create one. I guess I decided that the risk of encountering such broken behavior on a random machine wasn’t worth the advantage of using pbuffers if they were available, especially because drivers were supposed to be moving towards FBO’s now.

My apologies for the oversight: I wasn’t thinking in terms of creating an offscreen buffer in the absence of an existing window. I guess a pbuffer is the only possible way to do this.

In any case, I no longer have this machine, and I have no idea how prevalent is its obviously extremely buggy driver. Probably not very. It’s probably safe to enable pbuffers by default (and, in hindsight, it was probably always safe enough).

David

Ah, okay. Well, it’s only a fallback anyways, as FBO’s are still preferred by the GLX pipe.

Just changed it to true.