GL3 has support for clip planes but they are used differently and
involve writing to a builtin output variable in the vertex shader. The
current clip plane code assumes it is only used with a fixed function
driver and tries to directly push to the matrix builtins. This
obviously won't work on GL3 so for now let's just disable clip planes.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 5f621589467ab961f5130590298dc8e26d658a92)
When a component-alpha texture is made using a GL3 context a GL_RED
texture is actually used and a swizzle is set up to hide it. However
if a framebuffer is then bound to that texture then when the bits are
queried this workaround will leak out of the API. To fix this it now
detects the situation and reports the number of red bits as the number
of alpha bits.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 425cfb2675912a2cbcaaaeed7c2196d563948222)
Previously when the context was initialised Cogl would query the
number of stencil bits and set a private feature flag to mark that it
can use the buffer for clipping if there was at least 3. The problem
with this is that the number of stencil bits returned by
GL_STENCIL_BITS depends on the currently bound framebuffer. This patch
adds an internal function to query the number of stencil bits in a
framebuffer and makes it use that instead when determining whether it
can push the clip using the stencil buffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e928d21516a6c07798655341f4f0f8e3c1d1686c)
Cogl publicly exposes the depth buffer state so we might as well have
a function to query the number of depth bits of a framebuffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 853143eb10387f50f8d32cf09af31b8829dc1e01)
The GL framebuffer driver now makes sure to bind the framebuffer
before counting the number of bits. Previously it would just query the
number of bits for whatever framebuffer happened to be used last.
In addition the virtual for querying the framebuffer bits has been
modified to take a pointer to a structure instead of a separate
pointer to each component. This should make it slightly more efficient
and easier to maintain.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e9c58b2ba23a7cebcd4e633ea7c3191f02056fb5)
This adds a test which creates two offscreen framebuffers, one with
just an alpha component texture and the other will a full RGBA
texture. The bit sizes of both framebuffers are then checked to verify
that they either have or haven't got bits for the RGB components.
The test currently fails because the framebuffer functions don't bind
the framebuffer before querying so they just query whichever
framebuffer happened to be used last.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 7ca01373efe908efc9f18f2cb7f4a51c274ef677)
The GL3 context is created using the glXCreateContextAttribs function
which is part of the GLX_ARB_create_context extension. However
previously the function pointers from GLX extensions were only
retrieved once the GL context is created. That meant that the GL3
context creation function would always assume that the extension is
not supported so it would always fail.
This patch changes it to query the functions when the renderer is set
up instead. The base winsys feature flags that are determined while
querying the functions are stored in a member of CoglGLXRenderer.
These are then copied to the CoglContext when it is initialised.
The spec for glXGetProcAddress says that the functions returned are
context-independent. That implies that it is safe to call it without
binding a context although that is not explicitly stated as far as I
can tell. A big of googling finds this DRI documentation which says it
can be used without a context:
http://dri.freedesktop.org/wiki/glXGetProcAddressNeverReturnsNULL
And also this code sample:
http://www.opengl.org/wiki/Tutorial:_OpenGL_3.0_Context_Creation_%28GLX%29
One point that makes me concerned that this might not always work in
practice is that the code in SDL2 to create a GL3 context first
creates a dummy GL2 context in order to have something bound before it
calls glXGetProcAddress. I think this may just be a misunderstanding
based on how wglGetProcAddress works however.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 04a7aca9a98e84e43ac5559305a1358112902e30)
This adds a conformance test which renders a rectangle texture using
the two wrap modes clamp-to-edge and repeat. It then verifies that the
correct region of the texture is drawn for the texture coordinates
that are > 1.0.
The test currently always fails. The cogl_framebuffer_draw_rectangle
function is documented to always take normalized texture coordinates
regardless of the coordinate system of the texture. This works
correctly if all of the texture coordinates are in the range [0.0,1.0]
because cogl-primitives uses a different code path in that case.
However if the multiple-quad code path is taken then the coordinates
actually need to un-normalized for it to work.
There is a comment in cogl_meta_texture_foreach_in_region() which
implies that the incoming coordinates should always be normalized.
The documentation for the callback says that the resulting sub-texture
coordinates will always be in the coordinate system of the low-level
texture. However it doesn't work out like this because the meta
texture function uses the span iterating function which always returns
normalized coordinates. It looks like there needs to be some more
conversions going on somewhere.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit d2059bb32b8015060e10f41dbbb68d4230b47ddb)
_cogl_texture_spans_foreach_in_region first swaps over the texture
coordinates if they are flipped so that it can always iterate in a
positive direction. It sets a flag so that it will remember that the
coordinates are flipped. Before invoking the callback it is meant to
reflip the coordinates so that the callee doesn't need to be aware of
the flipping. However it was only flipping the sub-texture coordinates
and not the virtual coordinates. This was causing sliced textures to
draw their slice rectangles with the wrong geometry.
test-backface-culling was failing because of this.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit e7338a1e09cb22151374aefa6f0bb58485af9189)
There were a few problems with the sub texture iterating code of
sliced textures which were causing some conformance tests to fail when
NPOT textures are disabled:
• The spans are stored in un-normalized coordinates and the
coordinates passed to the foreach function are normalized. The
function was trying to un-normalize them before passing them to the
span iterator code but it was using the wrong factor which was
causing it to actually doubley normalize them.
• The shim function to renormalize the coordinates before passing them
to the callback was renormalizing the sub-texture coordinates
instead of the virtual coordinates. The sub-texture coordinates are
already in the right scale for whatever is the underlying texture so
we don't need to touch them. Instead we need to normalize the
virtual coordinates because these are coming from the un-normalized
coordinates that we passed to the span iterating code.
• The normalize factors passed to the span iterating were always 1.
The code uses this normalizing factor to round the incoming
coordinates to the nearest multiple of a full texture. It divides
the coordinates by the factor rather than multiplying so it looks
like we should be passing the virtual texture size here.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit c9773566b0ec0a17b34c440090529de8cff9609e)
This adds a cogl_texture_set_data function that is basically just a
convenience wrapper around cogl_texture_set_region. In the common case
where you want to upload the full contents of a mipmap level though this
api takes 4 less arguments (6 in total) so it's a bit simpler.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e651dbdc4e4f03016a3dee513e3680270a4a9142)
Consistent with how we lazily allocate framebuffers this patch allows us
to instantiate textures but still specify constraints and requirements
before allocating storage so that we can be sure to allocate the most
appropriate/efficient storage.
This adds a cogl_texture_allocate() function that is analogous to
cogl_framebuffer_allocate() which can optionally be called to explicitly
allocate storage and catch any errors. If this function isn't used
explicitly then Cogl will implicitly ensure textures are allocated
before the storage is needed.
It is generally recommended to rely on lazy storage allocation or at
least perform explicit allocation as late as possible so Cogl can be
fully informed about the best way to allocate storage.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 1fa7c0f10a8a03043e3c75cb079a49625df098b7)
Note: This reverts the cogl_texture_rectangle_new_with_size API change
that dropped the CoglError argument and keeps the semantics of
allocating the texture immediately. This is because Mutter currently
uses this API so we will probably look at updating this later once
we have a corresponding Mutter patch prepared. The other API changes
were kept since they only affected experimental api.
There was a lot of redundancy in how we tracked the width and height of
different texture types which is greatly simplified by adding width and
height members to CoglTexture directly and removing the get_width and
get_height vfuncs from CoglTextureVtable
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 3236e47723e4287d5e0023f29083521aeffc75dd)
This moves the _cogl_texture_get_gl_format function from cogl-texture.c
to cogl-texture-gl.c and renames it _cogl_texture_gl_get_format.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f8deec01eff7d8d9900b509048cf1ff1c86ca879)
This moves the direct use of GL in cogl-framebuffer.c for handling
cogl_framebuffer_read_pixels_into_bitmap() into
driver/gl/cogl-framebuffer-gl.c and adds a
->framebuffer_read_pixels_into_bitmap vfunc to CoglDriverVtable.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 2f893054d6754e6bc7983f061b27c7858f1a593c)
This remove cogl-internal.h in favour of using cogl-private.h. Some
things in cogl-internal.h were moved to driver/gl/cogl-util-gl-private.h
and the _cogl_gl_error_to_string function whose prototype was moved from
cogl-internal.h to cogl-util-gl-private.h has had its implementation
moved from cogl.c to cogl-util-gl.c
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 01cc82ece091aa3bec4c07fdd6bc9e5135fca573)
Symbols changed names, %1 makes gtk-doc sad and some referenced symbols
were missing in the -sections.txt file.
(cherry picked from commit c12919c321186ac7b223bc4f82c588ca2f199d67)
The libraries prefixes where never set in the configure script and
GDKPIXBUF_PREFIX had a typo.
(cherry picked from commit 5d8c0e13ed0572f806fdff2bff1d5904ed3bf69b)
For external (non gtk-doc even) constants, we can use <constant> to
correctly tag those without gtk-doc trying to cross-reference them.
(cherry picked from commit 78d22c6cd44a2279adcd2b94c3317292af861c70)
Another list to maintain by hand. We could split the variables declaring
the source files into private and public header in a separate Makefile
and then include it from both doc/reference/cogl/Makefile and
cogl/Makefile, but I'll leave this for the next person to look at the
documentation.
(cherry picked from commit f2daeb45fe118b848fbb2ad755d632d5699cd98b)
gtk-doc is not smart enough to parse things like:
typedef struct
{
...
} CoglFoo;
but needs the '{' at the end of the first line.
(cherry picked from commit d1187550ef547305fdeb8a22a7e39a95611a0e1d)
gtk-doc needs the types in -sections.txt to be able to do
cross-references. Add all those currently generating warnings.
(cherry picked from commit e57a21d2608f0885e6f2eb3a017feb7dffb7a63c)
That's actually for signals in gtk-doc and we're not dealing with
GObjects so it's not really appropriate. Used <structfield> as it's the
closest tag I could find to describe a 'property' of a CoglObject and
gives a generic style in the produced HTML.
(cherry picked from commit 8b485d57577cff227a0c7a2e6c06d8d277821374)
I just added the general types creating warnings in the current state of the
documentation (ie the ones references by already documented functions)
and moved the section from the 'Utility' section to the 'General'
section which I believe is a better fit as they are used by more than
one type and not really utilities.
(cherry picked from commit c51b147789763863ef32482d7ffa936160ed7c93)
Various changes have led to the current, separate from the pipeline,
depth state, this commit fixes the remaining waring around that.
(cherry picked from commit 111e687e722ad67a0e1c09f881c6282ccb06410b)
Instead of just having the reference at the end of the paragraph.
Usually seen as more usable.
(cherry picked from commit 6988d3ae61ab16fb298b34d2bd31860833f04186)
Argument names and @$arg suffered from various little mismatches, fix
them in a batch commit.
(cherry picked from commit d2ac3c5a88d980e7519c98bd261111b93cf73a6e)
Types need to be declare to be cross-referenceable. Use the opportunity
to reorganise the symbols in subsections.
(cherry picked from commit 95be47bc2aeea208c28d7df0b82aa63cc132f71e)
cogl-index-range was the old API, update the section name to match what
is declared in the documentation. Also update the short description to
better match the new API.
(cherry picked from commit d73df38ff2a8ebe477e139e5ac20838c8f4364bb)
