Currently features are represented as bits in a 32bit mask so we
obviously can't have more than 32 features with that approach. The new
approach is to use the COGL_FLAGS_ macros which lets us handle bitmasks
without a size limit and we change the public api to accept individual
feature enums instead of a mask. This way there is no limit on the
number of features we can add to Cogl.
Instead of using cogl_features_available() there is a new
cogl_has_feature() function and for checking multiple features there is
cogl_has_features() which takes a zero terminated vararg list of
features.
In addition to being able to check for individual features this also
adds a way to query all the features currently available via
cogl_foreach_feature() which will call a callback for each feature.
Since the new functions take an explicit context pointer there is also
no longer any ambiguity over when users can first start to query
features.
Reviewed-by: Neil Roberts <neil@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 adds a new experimental function, cogl_clip_push_primitive, that
allows you to push a CoglPrimitive onto the clip stack. The primitive
should describe a flat 2D shape and the geometry shouldn't include any
self intersections. When pushing a primitive you also need to tell
Cogl what the bounding box of that shape is (in shape local coordinates)
so that Cogl is able to efficiently update the required region of the
stencil buffer.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
As part of the on going, incremental effort to purge the non type safe
CoglHandle type from the Cogl API this patch tackles most of the
CoglHandle uses relating to textures.
We'd postponed making this change for quite a while because we wanted to
have a clearer understanding of how we wanted to evolve the texture APIs
towards Cogl 2.0 before exposing type safety here which would be
difficult to change later since it would imply breaking APIs.
The basic idea that we are steering towards now is that CoglTexture
can be considered to be the most primitive interface we have for any
object representing a texture. The texture interface would provide
roughly these methods:
cogl_texture_get_width
cogl_texture_get_height
cogl_texture_can_repeat
cogl_texture_can_mipmap
cogl_texture_generate_mipmap;
cogl_texture_get_format
cogl_texture_set_region
cogl_texture_get_region
Besides the texture interface we will then start to expose types
corresponding to specific texture types: CoglTexture2D,
CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and
CoglTexturePixmapX11.
We will then also expose an interface for the high-level texture types
we have (such as CoglTexture2DSlice, CoglSubTexture and
CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an
additional interface that lets you iterate a virtual region of a meta
texture and get mappings of primitive textures to sub-regions of that
virtual region. Internally we already have this kind of abstraction for
dealing with sliced texture, sub-textures and atlas textures in a
consistent way, so this will just make that abstraction public. The aim
here is to clarify that there is a difference between primitive textures
(CoglTexture2D/3D) and some of the other high-level textures, and also
enable developers to implement primitives that can support meta textures
since they can only be used with the cogl_rectangle API currently.
The thing that's not so clean-cut with this are the texture constructors
we have currently; such as cogl_texture_new_from_file which no longer
make sense when CoglTexture is considered to be an interface. These
will basically just become convenient factory functions and it's just a
bit unusual that they are within the cogl_texture namespace. It's worth
noting here that all the texture type APIs will also have their own type
specific constructors so these functions will only be used for the
convenience of being able to create a texture without really wanting to
know the details of what type of texture you need. Longer term for 2.0
we may come up with replacement names for these factory functions or the
other thing we are considering is designing some asynchronous factory
functions instead since it's so often detrimental to application
performance to be blocked waiting for a texture to be uploaded to the
GPU.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
As part of an on-going effort to get cogl-pipeline.c into a more
maintainable state this splits out all the apis relating just to
layer state. This just leaves code relating to the core CoglPipeline
and CoglPipelineLayer design left in cogl-pipeline.c.
This splits out around 2k more lines from cogl-pipeline.c although we
are still left with nearly 4k lines so we still have some way to go!
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Since cogl-pipeline.c has become very unwieldy this make a start at
trying to shape this code back into a manageable state. This patche
moves all the API relating to core pipeline state into
cogl-pipeline-state.c. This doesn't move code relating to layer state
out nor does it move any of the code supporting the core design
of CoglPipeline itself.
This change alone factors out 2k lines of code from cogl-pipeline.c
which is obviously a good start. The next step will be to factor
out the layer state and then probably look at breaking all of this
state code down into state-groups.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This exposes the previously internal only
_cogl_framebuffer_get_red/green/blue/alpha_bits() functions as 2.0
experimental API.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
This updates the public wayland symbols to follow the pattern
cogl_wayland_blah instead of cogl_blah_wayland.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
we've got into a bit of a mess with how we name platform specific
symbols and files, so this is a first pass at trying to tidy that up.
All platform specific symbols should be named like
cogl_<platform>_symbol_name and similarly files should be named like
cogl-<platform>-filename.c
This patch tackles the X11 specific renderer/display APIs as a start.
Signed-off-by: Neil Roberts <neil@linux.intel.com>
This exposes a CoglTexture2D typedef and adds the following experimental
API:
cogl_is_texture_2d
cogl_texture_2d_new_with_size
cogl_texture_2d_new_from_data
cogl_texture_2d_new_from_foreign
Since this is experimental API you need to define
COGL_ENABLE_EXPERIMENTAL_API before including cogl.h.
Note: With these new entrypoints we now expect a CoglContext pointer to
be passed in, instead of assuming there is a default context. The aim is
that for Cogl 2.0 we won't have a default context so this is a step in
that direction.
Instead of simply extending the cogl_pipeline_ namespace to add api for
controlling the depth testing state we now break the api out. This adds
a CoglDepthState type that can be stack allocated. The members of the
structure are private but we have the following API to setup the state:
cogl_depth_state_init
cogl_depth_state_set_test_enabled
cogl_depth_state_get_test_enabled
cogl_depth_state_set_test_function
cogl_depth_state_get_test_function
cogl_depth_state_set_writing_enabled
cogl_depth_state_get_writing_enabled
cogl_depth_state_set_range
cogl_depth_state_get_range
This removes the following experimental API which is now superseded:
cogl_material_set_depth_test_enabled
cogl_material_get_depth_test_enabled
cogl_material_set_depth_test_function
cogl_material_get_depth_test_function
cogl_material_set_depth_writing_enabled
cogl_material_get_depth_writing_enabled
cogl_material_set_depth_range
cogl_material_get_depth_range
Once a CoglDepthState structure is setup it can be set on a pipeline
using cogl_pipeline_set_depth_state().
This is part of a broader cleanup of some of the experimental Cogl API.
One of the reasons for this particular rename is to switch away from
using the term "Array" which implies a regular, indexable layout which
isn't the case. We also want to strongly imply a relationship between
CoglBuffers and CoglIndexBuffers and be consistent with the
CoglAttributeBuffer and CoglPixelBuffer APIs.
This is part of a broader cleanup of some of the experimental Cogl API.
One of the reasons for this particular rename is to switch away from
using the term "Array" which implies a regular, indexable layout which
isn't the case. We also want to strongly imply a relationship between
CoglBuffers and CoglPixelBuffers and be consistent with the
CoglAttributeBuffer and CoglIndexBuffer APIs.
This is part of a broader cleanup of some of the experimental Cogl API.
One of the reasons for this particular rename is to switch away from
using the term "Array" which implies a regular, indexable layout which
isn't the case. We also want to have a strongly implied relationship
between CoglAttributes and CoglAttributeBuffers.
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.
Some places were using COGL_HAS_WIN32 but the only macro defined is
COGL_HAS_WIN32_SUPPORT. The similar macros such as COGL_HAS_XLIB are
only defined for compatibility with existing code but COGL_HAS_WIN32
was never defined so there's no need to support it.
One of the places was including the non-existant cogl-win32.h. This
has been removed because the file only temporarily existed during
development of the backend.
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 gives us a way to clearly track the internal Cogl API that Clutter
depends on. The aim is to split Cogl out from Clutter into a standalone
3D graphics API and eventually we want to get rid of any private
interfaces for Clutter so its useful to have a handle on that task.
Actually it's not as bad as I was expecting though.
This renames the two internal functions _cogl_get_draw/read_buffer
as cogl_get_draw_framebuffer and _cogl_get_read_framebuffer. The
former is now also exposed as experimental API.
Recently _cogl_swap_buffers_notify was added (in 142b229c5c) so that
Cogl would be notified when Clutter performs a swap buffers request for
a given onscreen framebuffer. It was expected this would be required for
the recent cogl_read_pixel optimization that was implemented (ref
1bdb0e6e98) but in the end it wasn't used.
Since it wasn't used in the end this patch removes the API.
This adds a new experimental function (you need to define
COGL_ENABLE_EXPERIMENTAL_API to access it) which takes us towards being
able to have a standalone Cogl API. This is really a minor aesthetic
change for now since all the GL context creation code still lives in
Clutter but it's a step forward none the less.
Since our current designs introduce a CoglDisplay object as something
that would be passed to the context constructor this provides a stub
cogl-display.h with CoglDisplay typedef.
_cogl_context_get_default() which Clutter uses to access the Cogl
context has been modified to use cogl_context_new() to initialize
the default context.
There is one rather nasty hack used in this patch which is that the
implementation of cogl_context_new() has to forcibly make the allocated
context become the default context because currently all the code in
Cogl assumes it can access the context using _COGL_GET_CONTEXT including
code used to initialize the context.
Previously we were applying the culling optimization to any actor
painted without considering that we may be painting to an offscreen
framebuffer where the stage clip isn't applicable.
For now we simply expose a getter for the current draw framebuffer
and we can assume that a return value of NULL corresponds to the
stage.
Note: This will need to be updated as stages start to be backed by real
CoglFramebuffer objects and so we won't get NULL in those cases.
OpenGL < 4.0 only supports integer based viewports and internally we
have a mixture of code using floats and integers for viewports. This
patch switches all viewports throughout clutter and cogl to be
represented using floats considering that in the future we may want to
take advantage of floating point viewports with modern hardware/drivers.
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.
This adds a stop-gap mechanism for Cogl to know when the window system
is requested to present the current backbuffer to the frontbuffer by
adding a _cogl_swap_buffers_notify function that backends are now
expected to call right after issuing the equivalent request to OpenGL
vie the platforms OpenGL binding layer. This (blindly) updates all the
backends to call this new function.
For now Cogl doesn't do anything with the notification but the intention
is to use it as part of a planned read-pixel optimization which will
need to reset some state at the start of each new frame.
To allow us to have gobject properties that accept a CoglMatrix value we
need to register a GType. This adds a cogl_gtype_matrix_get_type function
that will register a static boxed type called "CoglMatrix".
This adds a new section to the reference manual for GType integration
functions.
When COGL_ENABLE_EXPERIMENTAL_2_0_API is defined cogl.h will now include
cogl2-path.h which changes cogl_path_new() so it can directly return a
CoglPath pointer; it no longer exposes a prototype for
cogl_{get,set}_path and all the remaining cogl_path_ functions now take
an explicit path as their first argument.
The idea is that we want to encourage developers to retain path objects
for as long as possible so they can take advantage of us uploading the
path geometry to the GPU. Currently although it is possible to start a
new path and query the current path, it is not convenient.
The other thing is that we want to get Cogl to the point where nothing
depends on a global, current context variable. This will allow us to one
day define a sensible threading model if/when that is ever desired.
For now this new define is simply an alias for
COGL_ENABLE_EXPERIMENTAL_API but the intention is that we will also use
it to start experimenting with changes that need to break the existing
Cogl API in incompatible ways.
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.
A CoglPrimitive is a retainable object for drawing a single primitive,
such as a triangle strip, fan or list.
CoglPrimitives build on CoglVertexAttributes and CoglIndices which
themselves build on CoglVertexArrays and CoglIndexArrays respectively.
A CoglPrimitive encapsulates enough information such that it can be
retained in a queue (e.g. the Cogl Journal, or renderlists in the
future) and drawn at some later time.
A CoglVertexAttribute defines a single attribute contained in a
CoglVertexArray. I.e. a CoglVertexArray is simply a buffer of N bytes
intended for containing a collection of attributes (position, color,
normals etc) and a CoglVertexAttribute defines one such attribute by
specifying its start offset in the array, its type, the number of
components and the stride etc.
CoglIndices define a range of indices inside a CoglIndexArray. I.e. a
CoglIndexArray is simply a buffer of N bytes and you can then
instantiate multiple CoglIndices collections that define a sub-region of
a CoglIndexArray by specifying a start offset and an index data type.
This adds a new CoglVertexArray object which is a subclass of CoglBuffer
used to hold vertex attributes. A later commit will add a
CoglVertexAttribute API which will be used to describe the attributes
inside a CoglVertexArray.
A CoglIndexArray is a subclass of CoglBuffer and will be used to hold
vertex indices. A later commit will add a CoglIndices API which will
allow describing a range of indices inside a CoglIndexArray.
This exposes the idea of a stack of source materials instead of just
having a single current material. This allows the writing of orthogonal
code that can change the current source material and restore it to its
previous state. It also allows the implementation of new composite
primitives that may want to validate the current source material and
possibly make override changes in a derived material.
Clutter has now taken responsibility for managing its viewport,
projection matrix and view transform as part of ClutterStage so
_cogl_setup_viewport is no longer used by anything, and since it's quite
an obscure API anyway it's we've taken the opportunity to remove the
function.
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.
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.
cogl_ortho is one of those APIs whos style was, for better or worse,
copied from OpenGL and for some inexplicable reason the near and far
arguments are inconsistent with the left, right, top, bottom arguments
because they don't take z coordinates they take a "distance" which
should be negative for a plane behind the viewer.
This updates the documentation to explain this.
