On 7/22/11 5:40 PM, Robert Osfield wrote:
Hi Hartmut,
On Fri, Jul 22, 2011 at 4:09 PM, Hartmut Seichter
<[email protected]> wrote:
In general I think there quite some subtle differences between WGL, GLX, CGL
and EGL. Because EGL tries to be everybody darling things are a bit
long-winded and especially real embedded hardware can be fiddly. Also, EGL
does allow OpenVG contexts or shared contexts between GLES and VG, and in
that case you need a bound surface+context to create another (OpenVG)
context that you can add.
I don't yet understand the need for the make current where you have
put it, as the next call
in an OSG application would be a make current. The fact you have
added suggest to me that
some OpenGL calls are happening after GraphicsWindowX11::init() but
before the GraphicsWindowX11::makeCurrent(),
in which ase this a bug elsewhere.
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.
Regarding the EGL_<COLOR>_SIZE items. This might be a driver issue, but I
have enough devices here to see similar behavior with them - actually
leaving things at 0 (default) is probably the best way to handle that.
What
happens is that eglChooseConfig creates some random config just to
satisfy
some items in your attributes and a subsequent eglCreateWindowSurface
fails
then with a "Bad Config" error.
EGL_DEPTH_SIZE seemingly works with value of 1.
My tests are on a N900 and a few other devices.
I really don't feel comfortable with just leaving the RGBA all to
defaults, and explictly setting a value 0 certainly doesn't sound like
default. It seems wrong to me. Could you please documentation that
this is appropriate for EGL that lead down the path you have taken?
Please read the EGL documentation at Khronos, default is 0 or if you don't
want to set it its EGL_DONT_CARE like I had in my earlier patch -
http://www.khronos.org/files/egl-1-4-quick-reference-card.pdf
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.
Could you try values of 8 for red, green and blue? These are the
defaults under other
windowing combinations
The default on my testing device is a bog standard RGB565 (extracted
through XVisualInfo) but even setting it to that does not work in that
setup.
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 original code passes on the Traits::red, green, blue and alpha
values when creating a GLX context. The present code in svn/trunk
doesn't do this for EGL but does it correctly for GLX, so I would have
though we should be passing on these values rather than just leave the
values of 1.
I have tested and I am 100% sure that on the devices here setting it to 1
will not work for ES1 nor for ES2. We can argue that it should actually find
a correct one (and in the meantime point fingers at GLES driver
implementers) but you are probably better off with the EGL default (0) or
declaring it as EGL_DONT_CARE (-1) which usually finds a matching visual. I
had a quick try with traits-><color> and didn't got it working. I think the
traits relaxation kicked in for X11 and subsequently the values in the
traits are not the actual ones of the visual. I will have another try later.
The right thing to do would be to use the Traits values, and if this
fails to create a
valid context then resort to using EGL_DONT_CARE, but even this isn't really
correct. If users want to use EGL_DONT_CARE then it'd be appropriate to use
that in an explict setting of the Traits to EGL_DONT_CARE. If we have a buggy
drivers that required red, green, blue and alpha values of 0 then this
could also be
passed in.
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
--
Hartmut Seichter, PhD (HKU), Dipl.-Ing. (BUW)
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
