Hi Hartmut, On Wed, Jul 27, 2011 at 12:00 PM, Hartmut Seichter <[email protected]> wrote: > Well, the eglMakeCurrent is only the verbose method of making sure surface > and context are connected. I am aware that the next call triggered through > the renderloop would do the same. Just wanted to be on the safe side and > also clarify that neither surface nor context are "initialized" as the > ::init() would suggest until eglMakeCurrent has been called.
I don't believe this eglMakeCurrent() is required or is good programming. eglMakeCurrent() isn't part of initialization, it's a runtime function that one calls prior to using a context from a specific thread. >> Thanks for the refernce page. This page doesn't specify a default for >> the RGBA, but >> does explict say that a value 0 means no red/green/blue/alpha channel >> in the colour buffer. > > Basically its the same as the Traits defaults. Actually I have added code to > extract the exact bit counts from the XVisualInfo. As it turns out this > seems to be a specific TI OMAP 3xxx + SGX 5xx error. Other libraries have > the same issue. So, working around it the way I suggested might be futile. >> >> If your drivers are working with these 0 settings then it's almost >> certainly a bug in the driver. > > As mentioned above. Its a known bug in the GLES stack of the OMAP3 series > and therefore it appears on the two Beagleboards, the N900 and the Gumstix. I believe that the best way to solve this problem for these specific boards would be to pass in Traits::red,green,blue,alpha values of 0 when creating a graphics context. This way the core OSG doesn't make a hack to get things working for a specific bug on a specific piece of hardware. If we did merge the changes to use 0 then it'd break all other GLES/X11 systems. > I will clean up my patches and resubmit. I think adding the Hildon specific > Xatom could go into trunk without affecting the rest. Oh, and maybe the > eglBindAPI before eglChooseConfig. The Hildon specific Xatom looks dubious to me too. First up you should always check that it's actually supported before using it. Second there is full screen handling elsewhere in GraphicWindowX11 that makes sure things work when toggling between full screen and windowed mode. The change you made makes we wonder if onces created the window would constrain what one could do afterwards. See the GraphicsWindowX11::checkAndSendEventFullScreenIfNeeded(..) method to see how it's done for regular desktops. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
