CoglPixelFormat is not a good way of describing the internal
format of a texture because it's too specific given that we don't
actually have exact knowledge of the internal format used by the driver.
This makes cogl_texture_get_format private and in the future we'll
provide a better way of querying the channels and their precision.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit ffde82981f22bd0185a7f33e1e6e1479f4c295b8)
Note: Since we can't break API compatibility on the 1.x branch this adds
a cogl/deprecated/cogl-texture-deprecated.c file with a
cogl_texture_get_format() wrapper around the private api. This also
moves the cogl_texture_get_rowstride() and cogl_texture_ref/unref()
functions that were previously deprecated into cogl-texture-deprecated.c
This defers checking the internal format and whether accelerated
migration is supported until allocating the texture.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 83b05cbe3969789bc3ec78480c0937a6722efbf1)
Instead of throwing a CoglError exception if an application tries to
allocate a zero size atlas texture this make that a programmer error
instead.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit d3eaeedc86d408669b81d6c43ef2b0ab9d859c85)
It was an oversight when making the CoglAtlasTexture api public that we
continued to use the COGL_TEXTURE_INTERNAL_DEFINE macro. This updates
the code to now use COGL_TEXTURE_DEFINE which means the
cogl_is_atlas_texture() function will now be exported in the public api.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Lionel Landwerlin <llandwerlin@gmail.com>
(cherry picked from commit ecbe209f48be80fe45b48f92b277a2aee08d5704)
In preparation for removing the automagic cogl-auto-texture apis this
adds a more minimal version of the cogl_texture_new_with_size code to
cogl-atlas.c for creating textures used to migrate images out of an
atlas and to cogl-texture-pixmap-x11.c.
Note: It turned out that both of these minimal versions were the same so
I did consider keeping a shared utility, but since the implementations
are very small and potentially due to the differing requirements for
atlas and pixmap-x11 textures we might even want them to differ later I
chose to keep them separate.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6d64307483713e7a5a7ef554275619def51b840f)
Conflicts:
cogl/cogl-atlas.c
cogl/winsys/cogl-texture-pixmap-x11.c
This exposes the CoglAtlasTexture api, making the following public:
cogl_atlas_texture_new_with_size
cogl_atlas_texture_new_from_file
cogl_atlas_texture_new_from_data
cogl_atlas_texture_new_from_bitmap
The plan is to remove auto-texture apis like cogl_texture_new_from_file
since they are a bit too magic, but that means we need an explicit way
for users to allocate texture that will go in the atlas.
Although the _new_from_file() api is arguably redundant since you can
use _bitmap_new_from_file() followed by _atlas_texture_new_from_bitmap()
we don't want to loose any of the convenience that
cogl_texture_new_from_file() had.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit fe515e6063ba4c3ddb5cd00d2c8527d9a6336a12)
Conflicts:
cogl/Makefile.am
This removes the gl centric _cogl_texture_prepare_for_upload api from
cogl-texture.c and instead adds a _cogl_bitmap_convert_for_upload() api
which everything now uses instead. GL specific code that needed the gl
internal/format/type enums returned by _cogl_texture_prepare_for_upload
now use ->pixel_format_to_gl directly.
Since there was a special case optimization in
cogl_texture_new_from_file that aimed to avoid copying the temporary
bitmap that's created for the given file and allow conversions to
happen in-place the new _cogl_bitmap_convert_for_upload() api supports
converting in place depending on a 'can_convert_in_place' argument.
This ability to convert bitmaps in-place has been integrated across the
different components as appropriate.
In updating cogl-texture-2d-sliced.c this was able to remove a number of
other GL specific parts to how spans are setup.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit e190dd23c655da34b9c5c263a9f6006dcc0413b0)
Conflicts:
cogl/cogl-auto-texture.c
cogl/cogl.symbols
The free function for atlas textures was previously always assuming
that there will be a valid sub_texture pointer but this might not be
the case if the texture was never successfully allocated. This was
causing Cogl to crash if the application tries to make a texture that
can not fit in the atlas using the automagic texture API.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit a7a8b7aefc8cb03fe8b716bee06b3449a7dba85f)
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 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)
cogl_texture_set_region() and cogl_texture_set_region_from_bitmap() now
have a level argument so image data can be uploaded to a specific mipmap
level.
The prototype for cogl_texture_set_region was also updated to simplify
the arguments.
The arguments for cogl_texture_set_region_from_bitmap were reordered to
be consistent with cogl_texture_set_region with the source related
arguments listed first followed by the destination arguments.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 3a336a8adcd406b53731a6de0e7d97ba7932c1a8)
Note: Public API changes were reverted in cherry-picking this patch
This removes several uses of _COGL_GET_CONTEXT in cogl-atlas-texture.c.
Notably this involved making CoglPangoGlyphCache track an associated
CoglContext pointer which cogl-pango can pass to
_cogl_atlas_texture_new_with_size().
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit d66afbd0758539330490945c699a05c0749c76aa)
This adds a driver/gl/cogl-texture-gl.c file and moves some gl specific
bits from cogl-texture.c into it. The moved symbols were also given a
_gl_ infix and the calling code was updated accordingly.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 2c9e81de70cc02d72b1ce9013c49e39300a05b6a)
This splits out the very high level texture constructors that may
internally construct one of several types of lower level texture due to
various constraints.
This also updates the prototypes for these constructors to take an
explicit context pointer and return a CoglError consistent with other
texture constructors.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit a1cabfae6ad50c51006c608cdde7d631b7832e71)
This allows apps to catch out-of-memory errors when allocating textures.
Textures can be pretty huge at times and so it's quite possible for an
application to try and allocate more memory than is available. It's also
very possible that the application can take some action in response to
reduce memory pressure (such as freeing up texture caches perhaps) so
we shouldn't just automatically abort like we do for trivial heap
allocations.
These public functions now take a CoglError argument so applications can
catch out of memory errors:
cogl_buffer_map
cogl_buffer_map_range
cogl_buffer_set_data
cogl_framebuffer_read_pixels_into_bitmap
cogl_pixel_buffer_new
cogl_texture_new_from_data
cogl_texture_new_from_bitmap
Note: we've been quite conservative with how many apis we let throw OOM
CoglErrors since we don't really want to put a burdon on developers to
be checking for errors with every cogl api call. So long as there is
some lower level api for apps to use that let them catch OOM errors
for everything necessary that's enough and we don't have to make more
convenient apis more awkward to use.
The main focus is on bitmaps and texture allocations since they
can be particularly large and prone to failing.
A new cogl_attribute_buffer_new_with_size() function has been added in
case developers need to catch OOM errors when allocating attribute buffers
whereby they can first use _buffer_new_with_size() (which doesn't take a
CoglError) followed by cogl_buffer_set_data() which will lazily allocate
the buffer storage and report OOM errors.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit f7735e141ad537a253b02afa2a8238f96340b978)
Note: since we can't break the API for Cogl 1.x then actually the main
purpose of cherry picking this patch is to keep in-line with changes
on the master branch so that we can easily cherry-pick patches.
All the api changes relating stable apis released on the 1.12 branch
have been reverted as part of cherry-picking this patch so this most
just applies all the internal plumbing changes that enable us to
correctly propagate OOM errors.
This renames the set_filters and set_wrap_mode_parameters texture
virtual functions to gl_flush_legacy_texobj_filters and
gl_flush_legacy_texobj_wrap_modes respectively to clarify that they are
opengl driver specific and that they are only used to support the legacy
opengl apis for setting filters and wrap modes where the state is
associated with texture objects instead of being associated with sampler
objects.
This part of an effort to clearly delimit our abstraction over opengl so
that we can start to consider non-opengl backends for Cogl.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 6f78b8a613340d7c6b736e51a16c625f52154430)
As part of our on-going goal to remove our dependence on a global Cogl
context this patch adds a pointer to the context to each CoglTexture
so that the various texture apis no longer need to use
_COGL_GET_CONTEXT.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 83131072eea395f18ab0525ea2446f443a6033b1)
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 interface represents any textures that are backed by a single
texture in GL and that can be used directly with the
cogl_framebuffer_draw_attributes family of functions. This currently
equates to CoglTexture2D, CoglTexture3D and CoglTextureRectangle.
The interface currently has only one method called
cogl_primitive_set_auto_mipmap. This replaces the
COGL_TEXTURE_NO_AUTO_MIPMAP flag from the CoglTextureFlags parameter
in the constructors. None of the other flags in CoglTextureFlags make
sense for primitive textures so it doesn't seem like a good idea to
need them for primitive constructors.
There is a boolean in the vtable to mark whether a texture type is
primitive which the new cogl_is_primitive function uses. There is also
a new texture virtual called set_auto_mipmap which is only required to
be implemented for primitive textures.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds a context member to CoglBitmap which stores the context it
was created with. That way it can be used in texture constructors
which use a bitmap. There is also an internal private function to get
the context out of the bitmap which all of the texture constructors
now use. _cogl_texture_3d_new_from_bitmap has had its context
parameter removed so that it more closely matches the other bitmap
constructors.
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>
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 an internal function to get the type of the underlying
hardware texture for any CoglTexture. It can return one of three
values to represent 2D textures, 3D textures or rectangle textures.
The idea is that this can be used as a replacement for
cogl_texture_get_gl_texture when only the target is required to make
it a bit less GL-centric. The implementation adds a new virtual
function which all of the texture backends now implement.
The enum is in a public header because a later patch will want to use
it from the CoglPipeline API. We may want to consider making the
function public too later.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This exposes cogl_sub_texture_new() and cogl_is_sub_texture() as
experimental public API. Previously sub-textures were only exposed via
cogl_texture_new_from_sub_texture() so there wasn't a corresponding
CoglSubTexture type. A CoglSubTexture is a high-level texture defined as
a sub-region of some other parent texture. CoglSubTextures are high
level textures that implement the CoglMetaTexture interface which can
be used to manually handle texture repeating.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Since we've had several developers from admirable projects say they
would like to use Cogl but would really prefer not to pull in
gobject,gmodule and glib as extra dependencies we are investigating if
we can get to the point where glib is only an optional dependency.
Actually we feel like we only make minimal use of glib anyway, so it may
well be quite straightforward to achieve this.
This adds a --disable-glib configure option that can be used to disable
features that depend on glib.
Actually --disable-glib doesn't strictly disable glib at this point
because it's more helpful if cogl continues to build as we make
incremental progress towards this.
The first use of glib that this patch tackles is the use of
g_return_val_if_fail and g_return_if_fail which have been replaced with
equivalent _COGL_RETURN_VAL_IF_FAIL and _COGL_RETURN_IF_FAIL macros.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
CoglMetaTexture is an interface for dealing with high level textures
that may be comprised of one or more low-level textures internally. The
interface allows the development of primitive drawing APIs that can draw
with high-level textures (such as atlas textures) even though the
GPU doesn't natively understand these texture types.
There is currently just one function that's part of this interface:
cogl_meta_texture_foreach_in_region() which allows an application to
resolve the internal, low-level textures of a high-level texture.
cogl_rectangle() uses this API for example so that it can easily emulate
the _REPEAT wrap mode for textures that the hardware can't natively
handle repeating of.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
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>
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>
Instead of calling _cogl_texutre_prepare_for_upload in
cogl_texture_set_region_from_bitmap the call is now deferred to the
implementation of the virtual for set_region. This is needed if the
texture backend is using a different format for the actual GL texture
than what is reported by cogl_texture_get_format. This happens for
example with atlas textures which report the original internal format
specified when the texture was created but actually always store the
data in an RGBA texture.
Also when creating an atlas texture from a bitmap it was preparing the
bitmap to be uploaded to the original format instead of the format of
the actual texture used for the atlas. Then it was using
cogl_texture_set_region_from_bitmap to upload the 5 pieces to make the
copies of the edge pixels. This would end up converting the image to
the actual format 5 times. The atlas textures have now been changed to
prepare the bitmap for the right format.
https://bugzilla.gnome.org/show_bug.cgi?id=657840
Reviewed-by: Robert Bragg <robert@linux.intel.com>
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>
This adds cogl_atlas_texture_* functions to register a callback that
will get invoked whenever any of the CoglAtlas's the textures use get
reorganized. The callback is global and is not tied to any particular
atlas texture.
This adds a new function called _cogl_atlas_texture_new_with_size. The
old new_from_bitmap function now just calls this and updates the
texture with the data.
If an atlas texture's last reference is held by the journal or by the
last flushed pipeline then if an atlas migration is started it can
cause a crash. This is because the atlas migration will cause a
journal flush and can sometimes change the current pipeline which
means that the texture would be destroyed during migration.
This patch adds an extra 'post_reorganize' callback to the existing
'reorganize' callback (which is now renamed to 'pre_reorganize'). The
pre_reorganize callback is now called before the atlas grabs a list of
the current textures instead of after so that it doesn't matter if the
journal flush destroys some of those textures. The pre_reorganize
callback for CoglAtlasTexture grabs a reference to all of the textures
so that they can not be destroyed when the migration changes the
pipeline. In the post_reorganize callback the reference is removed
again.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2538
Previously when _cogl_atlas_texture_migrate_out_of_atlas is called it
would unreference the atlas texture's sub-texture before calling
_cogl_atlas_copy_rectangle. This would leave the atlas texture in an
inconsistent state during the copy. This doesn't normally matter but
if the copy ends up doing a render then the atlas texture may end up
being referenced. In particular it would cause problems if the texture
is left in a texture unit because then Cogl may try to call
get_gl_texture even though the texture isn't actually being used for
rendering. To fix this the sub texture is now unrefed after the copy
call instead.
The CoglDebugFlags are now stored in an array of unsigned ints rather
than a single variable. The flags are accessed using macros instead of
directly peeking at the cogl_debug_flags variable. The index values
are stored in the enum rather than the actual mask values so that the
enum doesn't need to be more than 32 bits wide. The hope is that the
code to determine the index into the array can be optimized out by the
compiler so it should have exactly the same performance as the old
code.
Instead of having a single journal per context, we now have a
CoglJournal object for each CoglFramebuffer. This means we now don't
have to flush the journal when switching/pushing/popping between
different framebuffers so for example a Clutter scene that involves some
ClutterEffect actors that transiently redirect to an FBO can still be
batched.
This also allows us to track state in the journal that relates to the
current frame of its associated framebuffer which we'll need for our
optimization for using the CPU to handle reading a single pixel back
from a framebuffer when we know the whole scene is currently comprised
of simple rectangles in a journal.
Previously atlasing would be disabled if the GL driver does not
support reading back texture data. This meant that atlasing would not
happen on GLES. However we also require that the driver support FBOs
and the texture data is only read back as a fallback if the FBO
fails. Therefore the atlas should be ok on GLES 2 which has FBO
support in core.
Previously Cogl would only ever use one atlas for textures and if it
reached the maximum texture size then all other new textures would get
their own GL texture. This patch makes it so that we create as many
atlases as needed. This should avoid breaking up some batches and it
will be particularly good if we switch to always using multi-texturing
with a default shader that selects between multiple atlases using a
vertex attribute.
Whenever a new atlas is created it is stored in a GSList on the
context. A weak weference is taken on the atlas using
cogl_object_set_user_data so that it can be removed from the list when
the atlas is destroyed. The atlas textures themselves take a reference
to the atlas and this is the only thing that keeps the atlas
alive. This means that once the atlas becomes empty it will
automatically be destroyed.
All of the COGL_NOTEs pertaining to atlases are now prefixed with the
atlas pointer to make it clearer which atlas is changing.
* cogl_texture_get_data() is converted to use
_cogl_texture_foreach_sub_texture_in_region() to iterate
through the underlying textures.
* When we need to read only a portion of the underlying
texture, we set up a FBO and use _cogl_read_pixels()
to read the portion we need. This is enormously more
efficient for reading a small portion of a large atlas
texture.
* The CoglAtlasTexture, CoglSubTexture, and CoglTexture2dSliced
implementation of get_texture() are removed.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2414
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.
_cogl_atlas_new now has two extra parameters to specify the format of
the textures it creates as well as a set of flags to modify the
behavious of the atlas. One of the flags causes the new textures to be
cleared and the other causes migration to avoid actually copying the
textures. This is needed to use CoglAtlas from the pango glyph cache
because it needs to use COGL_PIXEL_A_8 and to clear the textures as it
does not fill in the gaps between glyphs. It needs to avoid copying
the textures so that it can work on GL implementations without FBO
support.
Instead of storing a pointer to the CoglRectangleMap and a handle to
the atlas texture in the context, there is a now a separate data
structure called a CoglAtlas to manage these two. The context just
contains a pointer to this. The code to reorganise the atlas has been
moved from cogl-atlas-texture.c to cogl-atlas.c
This simply renames CoglAtlas to CoglRectangleMap without making any
functional changes. The old 'CoglAtlas' is just a data structure for
managing unused areas of a rectangle and it doesn't neccessarily have
to be used for an atlas so it wasn't a very good name.
When filtering on allowed formats for atlas textures, it now masks out
the BGR and AFIRST bits in addition to the premult bit. That way it
will accept RGB and RGBA formats in any component order.
In theory it could also accept luminance and alpha-only textures but I
haven't added this because presumably if the application has requested
these formats then it has some reason not to use a full RGB or RGBA
texture and we should respect that.
