The check for the point sprite feature got lost when the feature
functions header was combined for GL and GLES in dae02a99a.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The cogl_framebuffer_get_blue_bits was defined 2 times-fix to use the
correct define for cogl_framebuffer_get_alpha_bits
Reviewed-by: Neil Roberts <neil@linux.intel.com>
If the display has been setup up, we should destroy the underlying
objects that the winsys has created. This can be done by calling the
winsys->destroy_display() function in _free.
Then, in that function, and for the NULL and GDL EGL platform we can
destroy the surface we have created in the setup_display() function
(through create_context()).
This allows to have clutter create a "dummy" display in
cogl_renderer_check_onscreen_template(), then free it, then recreate the
context and the surface that will be the final ones.
https://bugzilla.gnome.org/show_bug.cgi?id=655355
If we are being called without any GDL specific call (either the plane
we want to render to or the swap chain length) we can provide sane
defaults to still be able to create a context and a surface.
https://bugzilla.gnome.org/show_bug.cgi?id=655355
The egl winsys has a few code paths depending on the platform we are
compiling for. The GDL platform needs those defined as well.
A few tweaks were needed here and there to make it compile again.
https://bugzilla.gnome.org/show_bug.cgi?id=655355
We weren't defining CLUTTER_CEX100_LIBGDL_PREFIX in the configure.ac and
thus failing to compile when selecting the EGL/GDL winsys. Take the
opportunity to rename that to COGL_CEX100_LIBGDL_PREFIX
https://bugzilla.gnome.org/show_bug.cgi?id=655355
AC_CHECK_HEADER(S) for eglext.h need include egl.h as it may not be done
for you.
The patch tries to integrate with the previous work to check if
GLES/egl.h ir EGL/egl.h should be included for egl.h.
The GLX winsys is only compatible with GL drivers so we now bail out
from cogl-winsys-glx.c:_cogl_winsys_renderer_connect if a GLES driver
has been chosen.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
When passing the EGL_NATIVE_PIXMAP_KHR target to eglCreateImage the
EGL_KHR_image_pixmap extension explicitly states that EGL_NO_CONTEXT
must also be passed so we are now careful to do this.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
When we need to guarantee that the glColorMask is re-asserted the next
time that a primitive is drawn it is not enough to just OR in the
LOGIC_OPS flag to ctx->current_pipeline_changes_since_flush because
_cogl_pipeline_flush_gl_state actually checks the age of the pipeline
before checking that. If the pipeline hasn't aged then we bail out
early. This makes sure we decrement
ctx->current_pipeline_changes_since_flush so the next time we come to
flush a pipeline we will see a differing age.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
In cogl_quaternion_init_from_array we were passing the address of the x
component as the destination for memcpy, but that was wrong at least
because w is actually the first member in the structure. Another
concern raised was whether it was safe to assume that there was no
padding within the CoglQuaternion struct with some compilers so we also
switch to explicitly indexing each element of the array we want to copy.
In practice I think it's pretty safe to assume that padding will only be
introduced to ensure members are naturally aligned, but being explicit
is readable and it can't hurt to be extra cautious.
Another good catch in bug #655228 was that in
cogl_quaternion_get_rotation_axis we had a copy and paste error at the
end where we finally extract the axis and we were repeatedly calculating
just the x component. Now we calculate the y and z components too.
Thanks to Bug #655228 for identifying these issues.
https://bugzilla.gnome.org/show_bug.cgi?id=655228
Reviewed-by: Neil Roberts <neil@linux.intel.com>
At the moment, on make install, libcogl-pango will link to the
version of libcogl that is installed system wide. This leads to
interesting problems when the version installed system wide is
incompatible with the version of cogl being built.
E.g., when building cogl-1.7.4 (with --enable-cogl-pango and
--prefix=/usr) on a system that has cogl-1.7.2 installed in /usr:
$ make
[...]
$ ldd cogl-pango/.libs/libcogl-pango.so | grep cogl
libcogl.so.2 => /var/tmp/cogl-1.7.4/cogl/.libs/libcogl.so.2 (0x00007eff4bfb2000)
$ make DESTDIR=/var/tmp/cogl-1.7.4/dest install
[...]
$ ldd /var/tmp/cogl-1.7.4/dest/usr/lib64/libcogl-pango.so | grep cogl
libcogl.so.1 => /usr/lib64/libcogl.so.1 (0x00007f4647747000)
This problem can be avoided by reordering libcogl_pango_la_LIBADD
to ensure that during make installs' relinking phase, libtool looks
at the libcogl in the build directory before the system wide libcogl.
https://bugzilla.gnome.org/show_bug.cgi?id=655026
Reviewed-By: Robert Bragg <robert@linux.intel.com>
Reviewed-By: Emmanuele Bassi <ebassi@linux.intel.com>
Previously, _cogl_get_proc_address had a fallback to resolve the
symbol using g_module_open(NULL) to get the symbol from anywhere in
the address space. The EGL backend ends up using this on some drivers
because eglGetProcAddress isn't meant to return a pointer for core
functions. This causes problems if something in the process is linking
against a different GL library, for example Cairo may be linking
against libGL itself. In this case it may end up resolving symbols
from the GL library even if GLES is being used.
This patch removes the fallback. The EGL version now has its own
fallback instead which passes the existing libgl_module from the
renderer to g_module_symbol so that it should only get symbols from
that library or its dependency chain. The GLX and WGL winsys only call
glXGetProcAddress and wglGetProcAddress. The stub winsys does however
continue using the global symbol lookup.
The internal _cogl_get_proc_address function has been renamed to
_cogl_renderer_get_proc_address because it needs a connected renderer
to work so it could be considered to be a renderer method. The pointer
to the renderer is passed down to the winsys backends so that it can
use the data attached to the renderer to get the module pointers.
https://bugzilla.gnome.org/show_bug.cgi?id=655412
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The template_pipeline variable in _cogl_pipeline_fragend_arbfp_start
was not being initialised if the program caches are disabled with
COGL_DEBUG=disable-program-caches so it would crash. The other
backends have a similar variable but they already initialise it.
https://bugzilla.gnome.org/show_bug.cgi?id=655400
This exposes 2 experimental functions that make it possible to upload a
subregion of a texture from a CoglBuffer by first wrapping the buffer as
a CoglBitmap and then allowing uploading of a subregion from a
CoglBitmap. The new functions are:
cogl_bitmap_new_from_buffer() and
cogl_texture_set_region_from_bitmap()
Actually for now we are exporting this API for practical reasons since
we already had this API internally and it enables a specific feature
that was requested, but it is worth nothing that it's quite likely we
will replace these with functions that don't involve the CoglBitmap API
at some point.
For reference: The CoglBitmap API was actually removed from the 2.0
experimental API reference manual some time ago because the hope was
that we'd come up with a neater replacement. It doesn't seem entirely
clear what the scope of the CoglBitmap api is so it has became a bit of
a dumping ground. CoglBitmap is used for image loading, as a means to
represent the layout of image data and also internally deals with format
conversions.
Note: Because we are avoiding including CoglBitmap as part of the 2.0
API these functions aren't currently included in the 2.0 reference
manual.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
As a bare minimum we want to ensure that are releases are able to build
with support for gles1, gles2, gl, egl and glx. Previously we only
checked the build with gl + glx enabled and our last release actually
missed a header file required for building with egl.
The changelog generation scripts used for releases are overly elaborate
and fragile. A Changelog is also no substitute for the Git log so now we
simply ship a static Changelog that points to the Git log instead.
in cogl-ext-functions.h we had one multitexture feature that checked for
the ARB_multitexture extension and if found it then expected to find
glActiveTexture and glClientActiveTexture. The problem is that the
multitexture extension is part of the core GLES 1 and 2 APIs except that
for GLES2 there is no glClientActiveTexture function. By trying to
handle it as one feature that meant that Cogl would fail to check the
multitexture extension which is a hard requirement for Cogl.
The reason this went unnoticed is because Cogl can indirectly end up
linked to an OpenGL library via cairo and so we were finding a
glClientActiveTexture symbol there. This highlights that we should
probably stop using g_module_open (NULL) when checking features and
instead we should use the module we opened in cogl-renderer.c.
This adds CoglPipeline and CoglFramebuffer support for setting a color
mask which is a bit mask defining which color channels should be written
to the current framebuffer.
The final color mask is the intersection of the framebuffer color mask
and the pipeline color mask. The framebuffer mask affects all rendering
to the framebuffer while the pipeline masks can be used to affect
individual primitives.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds 3 configure options to override the library name that gets
dlopened for GL, GLES and GLESv2. This could be useful for distro
maintainers who have an unusual name for the libraries (for example,
on OpenBSD the GL library appears to be called libGL.so.4). This could
at least be simpler than having to create a distro patch.
The configure options would be used like this:
./configure --with-gl-libname=libGL.so \
--with-gles1-libname=libGLESv1.so \
--with-gles2-libname=libGLESv2.so
https://bugzilla.gnome.org/show_bug.cgi?id=654593
Instead of using g_module_build_path with the short name of the GL
library (eg, "GL") and relying on glib to add the suffix and prefix,
the configure script now directly encodes the full name including the
version number (eg, "libGL.so.1"). This is necessary because distros
don't always install the non-versioned suffix for the library.
The GLES libraries are left without the version suffix because it's
not clear what should be placed here and I can't find any
documentation from Khronos to clarify this. Mesa seems to install a
file called libGLESv2.so.2 but the IMG SDK doesn't install any
versioned library. There is an example of dynamically loading
libGLESv2 in the Chromium source code and that does not use the
version suffix even though it does use the version suffix for GL. This
implies that it's at least fairly normal to load the unversioned name
for GLES.
https://bugzilla.gnome.org/show_bug.cgi?id=654593
When we moved all the GL function pointers to be part of CoglContext in
commit dae02a99a5 we made a mistake and started to OR in the private
COGL_PRIVATE_FEATURE_TEXTURE_2D_FROM_EGL_IMAGE feature flag into the non
private flags which would mean cogl would think the GL_OES_EGL_image
extension wasn't supported.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This test wasn't actually explicitly clearing the background to black
it was simply a fluke that some drivers clear the background when
allocating a new framebuffer.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This makes sure the egl winsys frees the private egl_tex_pixmap state if
in _cogl_winsys_texture_pixmap_x11_create if there is a failure to
create an EGLImage.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
If _cogl_winsys_texture_pixmap_x11_create() fails then implicitly no
private state has been associated with the given tex_pixmap. Since that
winsys isn't associated with it we explicitly set tex_pixmap->winsys =
NULL.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This ensures that tex_pixmap->use_winsys_texture is always initialized
during cogl_texture_pixmap_x11_new - either according to the result of
winsys->texture_pixmap_x11_create, or if the winsys doesn't support tfp
we explicitly initialize to FALSE.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The _cogl_context_check_gl_version function is meant to be called once
Cogl has a GL context so that it can check whether the context found
is supported by Cogl. However, only the stub winsys was calling this
and it was doing it before Cogl had a chance to retrieve the function
pointer for glString so it would just crash. This patch combines the
two functions into one so that _cogl_context_update_features returns a
gboolean and a GError. Then it can just check the context itself.
https://bugzilla.gnome.org/show_bug.cgi?id=654440
Reviewed-by: Robert Bragg <robert@linux.intel.com>
cogl_read_pixels returns image data in a top-down memory order, but
because OpenGL normally returns pixel data in a bottom-up order we
have to flip the data before returning it to the user. If the OpenGL
driver supports the GL_MESA_pack_invert extension though we can ask the
driver to return the data in a top-down order in the first place.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
cogl-winsys-egl-feature-functions.h was unconditionally depending on the
struct wl_display type being defined. This guards the check for the
"WL_bind_wayland_display" extension with
#ifdef COGL_HAS_EGL_PLATFORM_WAYLAND_SUPPORT
Signed-off-by: Neil Roberts <neil@linux.intel.com>
Instead of only exposing COGL_HAS_GLX_SUPPORT internally in config.h we
now expose it though the public cogl-defines.h header.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
This adds a getter and setter for requesting dithering to be enabled.
Dithering is a hardware dependent technique to increase the visible
color resolution beyond what the underlying hardware supports by playing
tricks with the colors placed into the framebuffer to give the illusion
of other colors. (For example this can be compared to half-toning used
by some news papers to show varying levels of grey even though their may
only be black and white are available).
The results of enabling dithering are platform dependent and may have no
effect.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
The CoglPipelineCache is now extended to store templates for state
affecting vertex shaders and combined programs. The GLSL fragend,
vertend and progend now uses this to get cached shaders and a program.
When a new pipeline is created it will now get hashed three times if
the GLSL backends are in use (once for the fragend, once for the
vertend and once for the progend). Ideally we should add some way for
the progend to check its cache before the fragends and vertends are
checked so that it can bypass them entirely if it can find a cached
combined program.
The pipeline cache is now handled in CoglPipelineCache instead of
directly in the ARBfp fragend. The flags needed to hash a pipeline
should be exactly the same for the ARBfp and GLSL fragends so it's
convenient to share the code. The hash table now stores the actual
pipeline as the value instead of the private data so that the two
fragends can attach their data to it. That way it's possible to use
the same pipeline key with ancestors that are using different
fragends.
The hash table is created with g_hash_table_new_full to set a
destructor for the key and value and there is a destructor for
CoglPipelineCache that gets called when the CoglContext is
destroyed. That way we no longer leak the pipelines and shader state
when the context is desroyed.
Previously the fragends had a separate private data pointer which was
used by the GLSL and ARBfp fragends to store a tiny struct containing
a single pointer to the ref-counted shader state. The space for the
private data pointer is reserved in all of the pipelines for all of
the potential backends. The vertends and progends however did this
differently by directly storing the pointer to the ref counted data
using cogl_object_set_user_data. This patch unifies the different
methods so that they all use cogl_object_set_user_data and the
fragends don't bother with the separate tiny allocation for the
private data. The private data pointer array has been removed from
CoglPipeline and the corresponding fragend virtual to free the private
data has also been removed because this can instead be done with the
destroy notify from the object user data.
The variable names used have been unified so that all of the vertends
and fragends name their data struct CoglPipelineShaderState and use a
variable called shader_state to refer to it. The progend uses
CoglPipelineProgramState and a variable called program_state.
This should also fix two potential bugs. the ARBfp fragend was
apprently leaking a reference to the private state when it creates the
private data because it was adding a reference before stroring the
pointer to the newly allocated data but the ref count is already set
to 1 on creation. The other potential bug is that the free function
for CoglPipeline was only calling the free_priv virtual for the
currently used fragend of the pipeline. The design of the fragends is
meant to allow a pipeline to have multiple fragend priv datas because
a child pipeline could be attaching its fragend data to the ancestor
and its allowed to pick a different fragend.
