When the GL_EXT_unpack_subimage extension is not available and a
subregion of a texture is uploaded then it should first copy the
subregion to a newly allocated bitmap. However it was then later still
trying to prepare the upload using the original src_x and src_y values
which would cause an assertion failure. This patch fixes it to just
reset those to zero if the subregion is first copied.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 6f9a62db6f846f1d76e3ca16d9d8cdadf82a7009)
Until now, we hardcoded the internal format to GL_RGBA and used the
internal format returned by pixel_format_to_gl() as the format for
checking the texture size and format we're asked to create.
Let's use the proper internal format/format from now on.
This is needed as a later patch introduces DEPTH and DEPTH_STENCIL
textures.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit ec45f60ee2545f88302da314bcdbe1439c4ba9c9)
The coding style has for a long time said to avoid using redundant glib
data types such as gint or gchar etc because we feel that they make the
code look unnecessarily foreign to developers coming from outside of the
Gnome developer community.
Note: When we tried to find the historical rationale for the types we
just found that they were apparently only added for consistent syntax
highlighting which didn't seem that compelling.
Up until now we have been continuing to use some of the platform
specific type such as gint{8,16,32,64} and gsize but this patch switches
us over to using the standard c99 equivalents instead so we can further
ensure that our code looks familiar to the widest range of C developers
who might potentially contribute to Cogl.
So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this
switches all Cogl code to instead use the int{8,16,32,64}_t and
uint{8,16,32,64}_t c99 types instead.
Instead of gsize we now use size_t
For now we are not going to use the c99 _Bool type and instead we have
introduced a new CoglBool type to use instead of gboolean.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
Removing CoglHandle has been an on going goal for quite a long time now
and finally this patch removes the last remaining uses of the CoglHandle
type and the cogl_handle_ apis.
Since the big remaining users of CoglHandle were the cogl_program_ and
cogl_shader_ apis which have replaced with the CoglSnippets api this
patch removes both of these apis.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6ed3aaf4be21d605a1ed3176b3ea825933f85cf0)
Since the original patch was done after removing deprecated API
this back ported patch doesn't affect deprecated API and so
actually this cherry-pick doesn't remove all remaining use of
CoglHandle as it did for the master branch of Cogl.
The Intel driver currently has an optimisation when calling
glReadPixels into a PBO so that it will use a blit instead of the Mesa
fallback path. However this only works if the GL_PACK_ALIGNMENT is
exactly 1, even if this would be equivalent to a higher alignment
value because the bpp*width is already aligned. To make it more likely
to hit this fast path, we now detect this situation and explicitly use
an alignment of 1. To make this work the texture driver needs to be
passed down the bpp*width as well as the rowstride when configuring
the alignment.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This extension lets you upload texture data from a subregion of a
buffer by passing GL_UNPACK_ROW_LENGTH, GL_UNPACK_SKIP_PIXELS and
GL_UNPACK_SKIP_ROWS to glPixelStore. When this extension is available
the GLES texture driver will now avoid making a copy of the bitmap
when a subregion is used.
Note that Mesa doesn't currently advertise this extension but I've
made a patch to propose it:
http://lists.freedesktop.org/archives/mesa-dev/2012-March/020191.html
Cogl already had a vtable for the texture driver. This ended up being
used for some things that are not strictly related to texturing such
as converting between pixel formats and GL enums. Some other functions
that are driver dependent such as updating the features were not
indirected through a vtable but instead switched directly by looking
at the ctx->driver enum value. This patch normalises to the two uses
by adding a separate vtable for driver functions not related to
texturing and moves the pixel format conversion functions to it from
the texture driver vtable. It also adds a context parameter to all of
the functions in the new driver vtable so that they won't have to rely
on the global context.
This creates a CoglBitmap which points into an existing buffer in
system memory. That way it can be used to create a texture or to read
pixel data into. The function replaces the existing internal function
_cogl_bitmap_new_from_data but removes the destroy notify call back.
If the application wants notification of destruction it can just use
the cogl_object_set_user_data function as normal. Internally there is
now a convenience function to create a bitmap for system memory and
automatically free the buffer using that mechanism.
The name of the function is inspired by
cairo_image_surface_create_for_data which has similar semantics.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The assert could use a 'default:' label but that would stop GCC from
giving a warning when a new enum value is added.
https://bugzilla.gnome.org/show_bug.cgi?id=671016
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The cogl.h header is meant to be the public header for including the 1.x
api used by Clutter so we should stop using that as a convenient way to
include all likely prototypes and typedefs. Actually we already do a
good job of listing the specific headers we depend on in each of the .c
files we have so mostly this patch just strip out the redundant
includes for cogl.h with a few fixups where that broke the build.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The _cogl_texture_driver_pixel_format_to_gl functions for OpenGL and
OpenGLES convert CoglPixelFormats into corresponding gl enums that can
be used to upload texture data. Previously we were only handling a few
specific formats but this patch updates the functions to handle all the
formats we know about. The functions now also switch() on the format so
that we will get build time warnings if we forget to handle new formats
in these functions.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This moves _cogl_get_format_bpp from cogl-bitmap.c to cogl.c and renames
it to _cogl_pixel_format_get_bytes_per_pixel. This makes it clearer that
it doesn't return bits per pixel and makes the naming consistent with
other cogl api. The prototype has been moved to cogl-private.h since it
seems we should be aiming to get rid of cogl-internal.h at some point.
The patch also adds a simple gtk-doc comment since we might want to make
this api public.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The GL or GLES library is now dynamically loaded by the CoglRenderer
so that it can choose between GL, GLES1 and GLES2 at runtime. The
library is loaded by the renderer because it needs to be done before
calling eglInitialize. There is a new environment variable called
COGL_DRIVER to choose between gl, gles1 or gles2.
The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have
been changed so that they don't assume the ifdefs are mutually
exclusive. They haven't been removed entirely so that it's possible to
compile the GLES backends without the the enums from the GL headers.
When using GLX the winsys additionally dynamically loads libGL because
that also contains the GLX API. It can't be linked in directly because
that would probably conflict with the GLES API if the EGL is
selected. When compiling with EGL support the library links directly
to libEGL because it doesn't contain any GL API so it shouldn't have
any conflicts.
When building for WGL or OSX Cogl still directly links against the GL
API so there is a #define in config.h so that Cogl won't try to dlopen
the library.
Cogl-pango previously had a #ifdef to detect when the GL backend is
used so that it can sneakily pass GL_QUADS to
cogl_vertex_buffer_draw. This is now changed so that it queries the
CoglContext for the backend. However to get this to work Cogl now
needs to export the _cogl_context_get_default symbol and cogl-pango
needs some extra -I flags to so that it can include
cogl-context-private.h
The texture driver functions are now accessed through a vtable pointed
to by a struct in the CoglContext so that eventually it will be
possible to compile both the GL and GLES texture drivers into a single
binary and then select between them at runtime.
cogl-ext-functions.h now contains definitions for all of the core GL
and GLES functions that we would normally link to directly. All of the
code has changed to access them through the cogl context pointer. The
GE macro now takes an extra parameter to specify the context because
the macro itself needs to make GL calls but various points in the Cogl
source use different names for the context variable.
Instead of storing all of the feature function pointers in the driver
specific data of the CoglContext they are now all stored directly in
CoglContext. There is a single header containing the description of
the functions which gets included by cogl-context.h. There is a single
function in cogl-feature-private.c to check for all of these
functions.
The name of the function pointer variables have been changed from
ctx->drv.pf_glWhatever to just ctx->glWhatever.
The feature flags that get set when an extension is available are now
separated from the table of extensions. This is necessary because
different extensions can mean different things on GLES and GL. For
example, having access to glMapBuffer implies read and write support
on GL but only write support on GLES. The flags are instead set in the
driver specific init function by checking whether the function
pointers were successfully resolved.
_cogl_feature_check has been changed to assume the feature is
supported if any of the listed extensions are available instead of
requiring all of them. This makes it more convenient to specify
alternate names for the extension. Nothing else had previously listed
more than one name for an extension so this shouldn't cause any
problems.
When uploading data for GLES we need to deal with cases where the
rowstride is too large to be described only by GL_UNPACK_ALIGNMENT
because there is no GL_UNPACK_ROW_LENGTH. Previously for the
sub-region uploading code it would always copy the bitmap and for the
code to upload the whole image it would copy the bitmap unless the
rowstride == bpp*width. Neither paths took into account that we don't
need to copy if the rowstride is just an alignment of bpp*width. This
moves the bitmap copying code to a separate function that is used by
both upload methods. It only copies the bitmap if the rowstride is not
just an alignment of bpp*width.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2491
The GLES2 wrapper is no longer needed because the shader generation is
done within the GLSL fragend and vertend and any functions that are
different for GLES2 are now guarded by #ifdefs.
When uploading a 3D texture with an awkward rowstride, on GLES Cogl
will copy the images to an intermediate buffer to pass to GL. However
it was using the wrong height when copying the data so it would end up
overflowing the buffer and crashing.
This applies an API naming change that's been deliberated over for a
while now which is to rename CoglMaterial to CoglPipeline.
For now the new pipeline API is marked as experimental and public
headers continue to talk about materials not pipelines. The CoglMaterial
API is now maintained in terms of the cogl_pipeline API internally.
Currently this API is targeting Cogl 2.0 so we will have time to
integrate it properly with other upcoming Cogl 2.0 work.
The basic reasons for the rename are:
- That the term "material" implies to many people that they are
constrained to fragment processing; perhaps as some kind of high-level
texture abstraction.
- In Clutter they get exposed by ClutterTexture actors which may be
re-inforcing this misconception.
- When comparing how other frameworks use the term material, a material
sometimes describes a multi-pass fragment processing technique which
isn't the case in Cogl.
- In code, "CoglPipeline" will hopefully be a much more self documenting
summary of what these objects represent; a full GPU pipeline
configuration including, for example, vertex processing, fragment
processing and blending.
- When considering the API documentation story, at some point we need a
document introducing developers to how the "GPU pipeline" works so it
should become intuitive that CoglPipeline maps back to that
description of the GPU pipeline.
- This is consistent in terminology and concept to OpenGL 4's new
pipeline object which is a container for program objects.
Note: The cogl-material.[ch] files have been renamed to
cogl-material-compat.[ch] because otherwise git doesn't seem to treat
the change as a moving the old cogl-material.c->cogl-pipeline.c and so
we loose all our git-blame history.
*** WARNING: THIS COMMIT CHANGES THE BUILD ***
Do not recurse into the backend directories to build private, internal
libraries.
We only recurse from clutter/ into the cogl sub-directory; from there,
we don't recurse any further. All the backend-specific code in Cogl and
Clutter is compiled conditionally depending on the macros defined by the
configure script.
We still recurse from the top-level directory into doc, clutter and
tests, because gtk-doc and tests do not deal nicely with non-recursive
layouts.
This change makes Clutter compile slightly faster, and cleans up the
build system, especially when dealing with introspection data.
Ideally, we also want to make Cogl part of the top-level build, so that
we can finally drop the sed trick to change the shared library from the
GIR before compiling it.
Currently disabled:
‣ OSX backend
‣ Fruity backend
Currently enabled but untested:
‣ EGL backend
‣ Windows backend
