This adds a new renderer constraint enum:
COGL_RENDERER_CONSTRAINT_SUPPORTS_GLES2_CONTEXT
that can be used by applications to ensure the renderer they connect to
has support for creating a GLES2 context via cogl_gles2_context_new().
The cogl-gles2-context and cogl-gles2-gears examples and the conformance
tests have been updated to use this constraint.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ed61463d7194354b26624e8014859f0fbfc06a12)
Since 5967dad2400d32c we have stopped using glib types such as guint16
and guint32 in favour of the equivalent c99 types such as uint16_t and
uint32_t. When that patch was tested we must have used a configuration
that just happened to include <stdint.h> because we have since seen that
builds can fail due to missing c99 typedefs. This patch explicitly
includes stdint.h in cogl-types.h.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit c1e2220a4314071482d2d5638688b6bcf83882a2)
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.
This adds a comment to cogl-types.h where we define all the
CoglPixelFormat enums to give lots of information about the internal
representation of the format and to explain how new formats should be
allocated.
This information came from the discussion in bug #660188
Reviewed-by: Neil Roberts <neil@linux.intel.com>
30-bit color depth formats are defined by using value 13 in the least
significant nibble of the pixel format enumeration. This nibble
encodes bytes-per-pixel and byte alignment.
The _cogl_pixel_format_get_bytes_per_pixl() function is updated
accordingly to support these new formats.
https://bugzilla.gnome.org/show_bug.cgi?id=660188
edit: dropped the X101010 formats but also added 1010102 formats since
Cogl avoids exposing any padded formats and leaves it to applications to
consider the A component to be padding as needed. -- Robert Bragg
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Although these are in the public headers we should assume that no one is
using them since they were never documented so no could know what they
are useful for.
If you were to guess you'd be forgiven for thinking they were bitmasks
for checking some flags to see if a format is 24 or 32 bits. If you
looked further you might instead be forgiven for thinking that if you
masked of the least significant nibble of a pixel-format then you could
check the value against these defines. Neither of the previous
operations are reliable ways to check if a format is 24 or 32bit and
instead code must use then internal
_cogl_pixel_format_get_bytes_per_pixel() api if they want to know the
pixel size for a given format which relies on a 16 entry lookup table
using the least significant nibble of a pixel-format.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Although it's in a public header nothing should be using this define
since it's not documented what it could be used for. The cases where we
were using it internally were quite fragile because they were trying to
mask information from the least significant nibble of CoglPixelFormat
but really that nibble just has to be dealt with using lookup tables.
The least significant nibble of a pixel format gives information about
the bytes per pixel and whether the components are byte aligned but the
information needs to be accessed using
_cogl_pixel_format_get_byes_per_pixel() and
_cogl_pixel_format_is_endian_dependant().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Since (A & ~COGL_PREMULT_BIT) is basically as readable as (A &
COGL_UNPREMULT_MASK) this patch removes the mask define. Without the
mask the code is slightly more explicit and there's less risk in error
caused by us forgetting to update the COGL_UNPREMULT_MASK if the way
CoglPixelFormat is defined evolves.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
So we can get to the point where cogl.h is merely an aggregation of
header includes for the 1.x api this moves all the function prototypes
and type definitions into a cogl-context.h and a new cogl1-context.h.
Ideally no code internally should ever need to include cogl.h as it just
represents the public facing header for accessing the 1.x api which
should only be used by Clutter.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This adds two new experimental public functions to replace the old
internal _cogl_pipeline_set_cull_face_state function:
void
cogl_pipeline_set_cull_face_mode (CoglPipeline *pipeline,
CoglPipelineCullFaceMode cull_face_mode);
void
cogl_pipeline_set_front_face_winding (CoglPipeline *pipeline,
CoglWinding front_winding);
There are also the corresponding getters.
https://bugzilla.gnome.org/show_bug.cgi?id=663628
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Xlib headers define many trivially named objects which can later cause
name collision problems when only cogl.h header is included in a program
or library. Xlib headers are now only included through including the
standalone header cogl-xlib.h.
https://bugzilla.gnome.org/show_bug.cgi?id=661174
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This make the CoglTexture2DSliced type public and adds
cogl_texture_2d_sliced_new_with_size() as an experimental API that can
be used to construct a sliced texture without any initial data.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This patch basically restores the logic from 1.6. There we assumed that
glXCopySubBuffer won't tear and thus only needs to be throttled to the
framerate, while glBlitFramebuffer needs to always wait to avoid
tearing.
With Nvidia drivers specifically we have seen that glBlitFramebuffer is
not synchronized. Eventually the plan is that Cogl will actually take
into consideration the underlying driver/hw vendor and driver version
and we may want to only mark glBlitFramebuffer un-synchronized on
Nvidia.
https://bugzilla.gnome.org/show_bug.cgi?id=659360
Reviewed-by: Robert Bragg <robert@linux.intel.com>
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 Xlib and Win32 typesafe replacements for
cogl_renderer_handle_native_event, cogl_renderer_add_native_filter,
cogl_renderer_remove_native_filter. The old functions are kept as an
implementation detail so we can share code.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
To help catch accidental changes to the size of public structs that can
be allocated on the stack this patch adds compile time checks that our
struct sizes haven't changed.
This adds an experimental CoglEuler data type and the following new
functions:
cogl_euler_init
cogl_euler_init_from_matrix
cogl_euler_init_from_quaternion
cogl_euler_equal
cogl_euler_copy
cogl_euler_free
cogl_quaternion_init_from_euler
Since this is experimental API you need to define
COGL_ENABLE_EXPERIMENTAL_API before including cogl.h
This adds an experimental quaternion utility API. It's not yet fully
documented but it's complete enough that people can start to experiment
with using it. It adds the following functions:
cogl_quaternion_init_identity
cogl_quaternion_init
cogl_quaternion_init_from_angle_vector
cogl_quaternion_init_from_array
cogl_quaternion_init_from_x_rotation
cogl_quaternion_init_from_y_rotation
cogl_quaternion_init_from_z_rotation
cogl_quaternion_equal
cogl_quaternion_copy
cogl_quaternion_free
cogl_quaternion_get_rotation_angle
cogl_quaternion_get_rotation_axis
cogl_quaternion_normalize
cogl_quaternion_dot_product
cogl_quaternion_invert
cogl_quaternion_multiply
cogl_quaternion_pow
cogl_quaternion_slerp
cogl_quaternion_nlerp
cogl_quaternion_squad
cogl_get_static_identity_quaternion
cogl_get_static_zero_quaternion
Since it's experimental API you'll need to define
COGL_ENABLE_EXPERIMENTAL_API before including cogl.h.
Previously the mask of available winsys features was stored in a
CoglBitmask. That isn't the ideal type to use for this because it is
intended for a growable array of bits so it can allocate extra memory
if there are more than 31 flags set. For the winsys feature flags the
highest used bit is known at compile time so it makes sense to
allocate a fixed array instead. This is conceptually similar to the
CoglDebugFlags which are stored in an array of integers with macros to
test a bit in the array. This moves the macros used for CoglDebugFlags
to cogl-flags.h and makes them more generic so they can be shared with
CoglContext.
Instead of having cogl_renderer_xlib_add_filter and friends there is
now cogl_renderer_add_native_filter which can be used regardless of
the backend. The callback function for the filter now just takes a
void pointer instead of an XEvent pointer which should be interpreted
differently depending on the backend. For example, on Xlib it would
still be an XEvent but on Windows it could be a MSG. This simplifies
the code somewhat because the _cogl_xlib_add_filter no longer needs to
have its own filter list when a stub renderer is used because there is
always a renderer available.
cogl_renderer_xlib_handle_event has also been renamed to
cogl_renderer_handle_native_event. This just forwards the event on to
all of the listeners. The backend renderer is expected to register its
own event filter if it wants to process the events in some way.
This migrates all the GLX window system code down from the Clutter
backend code into a Cogl winsys. Moving OpenGL window system binding
code down from Clutter into Cogl is the biggest blocker to having Cogl
become a standalone 3D graphics library, so this is an important step in
that direction.
This is part of a broader cleanup of some of the experimental Cogl API.
One of the reasons for this particular rename is to reduce the verbosity
of using the API. Another reason is that CoglVertexArray is going to be
renamed CoglAttributeBuffer and we want to help emphasize the
relationship between CoglAttributes and CoglAttributeBuffers.
GLES has an extension called GL_OES_mapbuffer to support mapping
buffer objects but only for writing. Cogl now has two new feature
flags to advertise whether mapping for reading and writing is
supported. Under OpenGL, these features are always set if the VBO
extension is advertised and under GLES only the write flag is set if
the GL_OES_mapbuffer extension is advertised.
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.
This moves the CoglIndicesType and CoglVerticesMode typedefs from
cogl-vertex-buffer.h to cogl-types.h so they can be shared with the
anticipated cogl vertex attribute API.
This adds a publicly exposed experimental API for a 3D texture
backend. There is a feature flag which can be checked for whether 3D
textures are supported. Although we require OpenGL 1.2 which has 3D
textures in core, GLES only provides them through an extension so the
feature can be used to detect that.
The textures can be created with one of two new API functions :-
cogl_texture_3d_new_with_size
and
cogl_texture_3d_new_from_data
There is also internally a new_from_bitmap function. new_from_data is
implemented in terms of this function.
The two constructors are effectively the only way to upload data to a
3D texture. It does not work to call glTexImage2D with the
GL_TEXTURE_3D target so the virtual for cogl_texture_set_region does
nothing. It would be possible to make cogl_texture_get_data do
something sensible like returning all of the images as a single long
image but this is not currently implemented and instead the virtual
just always fails. We may want to add API specific to the 3D texture
backend to get and set a sub region of the texture.
All of those three functions can throw a GError. This will happen if
the GPU does not support 3D textures or it does not support NPOTs and
an NPOT size is requested. It will also fail if the FBO extension is
not supported and the COGL_TEXTURE_NO_AUTO_MIPMAP flag is not
given. This could be avoided by copying the code for the
GL_GENERATE_MIPMAP TexParameter fallback, but in the interests of
keeping the code simple this is not yet done.
This adds a couple of functions to cogl-texture-driver for uploading
3D data and querying the 3D proxy
texture. prep_gl_for_pixels_upload_full now also takes sets the
GL_UNPACK_IMAGE_HEIGHT parameter so that 3D textures can have padding
between the images. Whenever 3D texture is uploading, both the height
of the images and the height of all of the data is specified (either
explicitly or implicilty from the CoglBitmap) so that the image height
can be deduced by dividing by the depth.
We can use this error in more unsupported situations than just when we
have a Cogl feature flag for the error. For example if a non-sliced
texture is created with dimensions that are too large then we could
throw this error. Therefore it seems good to rename to something more
general.
This adds a new API call to enable point sprite coordinate generation
for a material layer:
void
cogl_material_set_layer_point_sprite_coords_enabled (CoglHandle material,
int layer_index,
gboolean enable);
There is also a corresponding get function.
Enabling point sprite coords simply sets the GL_COORD_REPLACE of the
GL_POINT_SPRITE glTexEnv when flusing the material. There is no
separate application control for glEnable(GL_POINT_SPRITE). Instead it
is left permanently enabled under the assumption that it has no affect
unless GL_COORD_REPLACE is enabled for a texture unit.
http://bugzilla.openedhand.com/show_bug.cgi?id=2047
This adds three new feature flags COGL_FEATURE_TEXTURE_NPOT_BASIC,
COGL_FEATURE_TEXTURE_NPOT_MIPMAP and COGL_FEATURE_TEXTURE_NPOT_REPEAT
that can tell you if your hardware supports non power of two textures,
npot textures + mipmaps and npot textures + wrap modes other than
CLAMP_TO_EDGE.
The pre-existing COGL_FEATURE_TEXTURE_NPOT feature implies all of the
above.
By default GLES 2 core supports npot textures but mipmaps and repeat
modes can only be used with power of two textures. This patch also makes
GLES check for the GL_OES_texture_npot extension to determine if mipmaps
and repeating are supported with npot textures.
This redirects the legacy depth testing APIs through CoglMaterial and
adds a new experimental cogl_material_ API for handling the depth
testing state.
This adds the following new functions:
cogl_material_set_depth_test_enabled
cogl_material_get_depth_test_enabled
cogl_material_set_depth_writing_enabled
cogl_material_get_depth_writing_enabled
cogl_material_set_depth_test_function
cogl_material_get_depth_test_function
cogl_material_set_depth_range
cogl_material_get_depth_range
As with other experimental Cogl API you need to define
COGL_ENABLE_EXPERIMENTAL_API to access them and their stability isn't
yet guaranteed.
• 3 general fixes (typos, copy/paste),
• ignore cogl-object-private.h,
• cogl_fixed_atani() was in reality cogl_fixed_atan(), fixed in commit
43564f05.
• Fix the cogl-vector section: sections must have a </SECTION> tag at
the end. Also the cogl-vector section was added in the middle of the
cogl-buffer one. Let's shiffle it out and add that </SECTION> tag.
CoglHandle is a common source of complaints and confusion because people
expect a "handle" to be some form of integer type with some indirection
to lookup the corresponding objects as opposed to a direct pointer.
This patch starts by renaming CoglHandle to CoglObject * and creating
corresponding cogl_object_ APIs to replace the cogl_handle ones.
The next step though is to remove all use of CoglHandle in the Cogl APIs
and replace with strongly typed pointer types such as CoglMaterial * or
CoglTexture * etc also all occurrences of COGL_INVALID_HANDLE can just
use NULL instead.
After this we will consider switching to GTypeInstance internally so we
can have inheritance for our types and hopefully improve how we handle
bindings.
Note all these changes will be done in a way that maintains the API and
ABI.
CoglColor and CoglMatrix have public declarations with private members
so that we are free to change the implementation but the structures
could still be allocated on the stack in applications. However it's
quite easy not to realise the members are private and then access them
directly. This patch wraps the members in a macro which redefines the
symbol name when including the header outside of the clutter source.
http://bugzilla.openedhand.com/show_bug.cgi?id=2065
Since using addresses that might change is something that finally
the FSF acknowledge as a plausible scenario (after changing address
twice), the license blurb in the source files should use the URI
for getting the license in case the library did not come with it.
Not that URIs cannot possibly change, but at least it's easier to
set up a redirection at the same place.
As a side note: this commit closes the oldes bug in Clutter's bug
report tool.
http://bugzilla.openedhand.com/show_bug.cgi?id=521
This adds a COGL_INDICES_TYPE_UNSIGNED_INT enum value so that unsigned
ints can be used with cogl_vertex_buffer_indices_new. Unsigned ints
are not supported in core on GLES so a feature flag has also been
added to advertise this. GLES only sets the feature if the
GL_OES_element_index_uint extension is available. It is an error to
call indices_new() with unsigned ints unless the feature is
advertised.
http://bugzilla.openedhand.com/show_bug.cgi?id=1998
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
First, let's add a new public feature called, surprisingly,
COGL_FEATURE_PBOS to check the availability of PBOs and provide a
fallback path when running on older GL implementations or on OpenGL ES
In case the underlying OpenGL implementation does not provide PBOs, we
need a fallback path (a malloc'ed buffer). The CoglPixelBufer
constructors will instanciate a subclass of CoglBuffer that handles
map/unmap and set_data() with a malloc'ed buffer.
The public feature is useful to check before using set_data() on a
buffer as it will mean doing a memcpy() when not supporting PBOs (in
that case, it's better to create the texture directly instead of using a
CoglBuffer).
This adds a CoglAtlas type which is a data structure that keeps track
of unused sub rectangles of a larger rectangle. There is a new atlased
texture backend which uses this to put multiple textures into a single
larger texture.
Currently the atlas is always sized 256x256 and the textures are never
moved once they are put in. Eventually it needs to be able to
reorganise the atlas and grow it if necessary. It also needs to
migrate the textures out of the atlas if mipmaps are required.
As part of an incremental process to have Cogl be a standalone project we
want to re-consider how we organise the Cogl source code.
Currently this is the structure I'm aiming for:
cogl/
cogl/
<put common source here>
winsys/
cogl-glx.c
cogl-wgl.c
driver/
gl/
gles/
os/ ?
utils/
cogl-fixed
cogl-matrix-stack?
cogl-journal?
cogl-primitives?
pango/
The new winsys component is a starting point for migrating window system
code (i.e. x11,glx,wgl,osx,egl etc) from Clutter to Cogl.
The utils/ and pango/ directories aren't added by this commit, but they are
noted because I plan to add them soon.
Overview of the planned structure:
* The winsys/ API is the API that binds OpenGL to a specific window system,
be that X11 or win32 etc. Example are glx, wgl and egl. Much of the logic
under clutter/{glx,osx,win32 etc} should migrate here.
* Note there is also the idea of a winsys-base that may represent a window
system for which there are multiple winsys APIs. An example of this is
x11, since glx and egl may both be used with x11. (currently only Clutter
has the idea of a winsys-base)
* The driver/ represents a specific varient of OpenGL. Currently we have "gl"
representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing
GLES 1.1 (fixed funciton) and 2.0 (fully shader based)
* Everything under cogl/ should fundamentally be supporting access to the
GPU. Essentially Cogl's most basic requirement is to provide a nice GPU
Graphics API and drawing a line between this and the utility functionality
we add to support Clutter should help keep this lean and maintainable.
* Code under utils/ as suggested builds on cogl/ adding more convenient
APIs or mechanism to optimize special cases. Broadly speaking you can
compare cogl/ to OpenGL and utils/ to GLU.
* clutter/pango will be moved to clutter/cogl/pango
How some of the internal configure.ac/pkg-config terminology has changed:
backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11"
backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la"
clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx"
CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS
clutterbackendlib -> CLUTTER_WINSYS_LIB
CLUTTER_COGL -> COGL_DRIVER # e.g. "gl"
Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps
As the first thing to take advantage of the new winsys component in Cogl;
cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into
cogl/common/cogl.c and this common implementation first trys
_cogl_winsys_get_proc_address() but if that fails then it falls back to
gmodule.
