isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-23 08:30:42 -05:00
Code Issues Packages Projects Releases Wiki Activity
2112af0bc5
mutter/cogl/cogl-texture-private.h

280 lines
10 KiB
C
Raw Normal View History

Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
/*
[cogl] Updates all file headers and removes lots of trailing white space Adds missing notices, and ensures all the notices are consistent. The Cogl blurb also now reads: * Cogl * * An object oriented GL/GLES Abstraction/Utility Layer
2009-04-27 10:48:12 -04:00
* Cogl
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
*
[cogl] Updates all file headers and removes lots of trailing white space Adds missing notices, and ensures all the notices are consistent. The Cogl blurb also now reads: * Cogl * * An object oriented GL/GLES Abstraction/Utility Layer
2009-04-27 10:48:12 -04:00
* An object oriented GL/GLES Abstraction/Utility Layer
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
*
[cogl] Updates all file headers and removes lots of trailing white space Adds missing notices, and ensures all the notices are consistent. The Cogl blurb also now reads: * Cogl * * An object oriented GL/GLES Abstraction/Utility Layer
2009-04-27 10:48:12 -04:00
* Copyright (C) 2007,2008,2009 Intel Corporation.
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
Remove mentions of the FSF address 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
2010-03-01 07:56:10 -05:00
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*
*
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
*/
Improve cogl-texture maintainability by moving 90% into cogl/common This splits the limited components that differed between cogl/{gl,gles}/cogl-texture.c into new {gl,gles}/cogl-texture-driver.c files and the rest that can now be shared into cogl/common/cogl-texture.c
2009-07-27 19:37:11 -04:00
#ifndef __COGL_TEXTURE_PRIVATE_H
#define __COGL_TEXTURE_PRIVATE_H
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
[cogl] Only expose CoglBitmap as a CoglHandle It was inconsistent that we exposed the CoglBitmap struct instead of an opaque CoglHandle.
2009-04-30 13:00:22 -04:00
#include "cogl-bitmap-private.h"
[cogl-handle] Optimize how we define cogl handles The cogl_is_* functions were showing up quite high on profiles due to iterating through arrays of cogl handles. This does away with all the handle arrays and implements a simple struct inheritance scheme. All cogl objects now add a CoglHandleObject _parent; member to their main structures. The base object includes 2 members a.t.m; a ref_count, and a klass pointer. The klass in turn gives you a type and virtual function for freeing objects of that type. Each handle type has a _cogl_##handle_type##_get_type () function automatically defined which returns a GQuark of the handle type, so now implementing the cogl_is_* funcs is just a case of comparing with obj->klass->type. Another outcome of the re-work is that cogl_handle_{ref,unref} are also much more efficient, and no longer need extending for each handle type added to cogl. The cogl_##handle_type##_{ref,unref} functions are now deprecated and are no longer used internally to Clutter or Cogl. Potentially we can remove them completely before 1.0.
2009-04-01 12:16:44 -04:00
#include "cogl-handle.h"
cogl: rename CoglMaterial -> CoglPipeline 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.
2010-10-27 13:54:57 -04:00
#include "cogl-pipeline-private.h"
meta-texture: This publicly exposes CoglMetaTexture 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>
2011-10-08 09:13:03 -04:00
#include "cogl-spans.h"
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
cogl: Move data only used for upload out of CoglTexture The CoglTexture struct previously contained some fields which are only used to upload data such as the CoglBitmap and the source GL format. These are now moved to a separate CoglTextureUploadData struct which only exists for the duration of one of the cogl_texture_*_new functions. In cogl-texture there are utility functions which operate on this new struct rather than on CoglTexture directly. Some of the fields that were previously stored in the CoglBitmap struct are now copied to the CoglTexture such as the width, height, format and internal GL format. The rowstride was previously stored in CoglTexture and this was publicly accessible with the cogl_texture_get_rowstride function. However this doesn't seem to be a useful function because there is no need to use the same rowstride again when uploading or downloading new data. Instead cogl_texture_get_rowstride now just calculates a suitable rowstride from the format and width of the texture.
2009-11-26 12:32:52 -05:00
typedef struct _CoglTextureVtable CoglTextureVtable;
Merged clutter-ivan branch into trunk. svn merge \ https://svn.o-hand.com/repos/clutter/trunk/clutter@2509 \ https://svn.o-hand.com/repos/clutter/branches/clutter-ivan@HEAD
2008-04-25 09:37:36 -04:00
Fix checks for out-of-bounds coordinates and repeats Add a return result from CoglTexture.transform_quad_coords_to_gl(), so that we can properly determine the nature of repeats in the face of GL_TEXTURE_RECTANGLE_ARB, where the returned coordinates are not normalized. The comment "We also work out whether any of the texture coordinates are outside the range [0.0,1.0]. We need to do this after calling transform_coords_to_gl in case the texture backend is munging the coordinates (such as in the sub texture backend)." is disregarded and removed, since it's actually the virtual coordinates that determine whether we repeat, not the GL coordinates. Warnings about disregarded layers are used in all cases where applicable, including for subtextures. http://bugzilla.openedhand.com/show_bug.cgi?id=2016 Signed-off-by: Neil Roberts <neil@linux.intel.com>
2010-03-01 16:49:04 -05:00
/* Encodes three possibiloities result of transforming a quad */
typedef enum {
/* quad doesn't cross the boundaries of a texture */
COGL_TRANSFORM_NO_REPEAT,
/* quad crosses boundaries, hardware wrap mode can handle */
COGL_TRANSFORM_HARDWARE_REPEAT,
/* quad crosses boundaries, needs software fallback;
* for a sliced texture, this might not actually involve
* repeating, just a quad crossing multiple slices */
COGL_TRANSFORM_SOFTWARE_REPEAT,
} CoglTransformResult;
cogl-texture: Replace the ensure_mipmaps virtual with pre_paint Instead of the ensure_mipmaps virtual that is only called whenever the texture is about to be rendered with a min filter that needs the mipmap, there is now a pre_paint virtual that is always called when the texture is about to be painted in any way. It has a flags parameter which is used to specify whether the mipmap will be needed. This is useful for CoglTexturePixmapX11 because it needs to do stuff before painting that is unrelated to mipmapping.
2010-06-09 12:39:59 -04:00
/* Flags given to the pre_paint method */
typedef enum {
/* The texture is going to be used with filters that require
mipmapping. This gives the texture the opportunity to
automatically update the mipmap tree */
COGL_TEXTURE_NEEDS_MIPMAP = 1
} CoglTexturePrePaintFlags;
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
struct _CoglTextureVtable
{
/* Virtual functions that must be implemented for a texture
backend */
cogl-texture: Share the common code in the set_region virtual There was a lot of common code that was copied to all of the backends to convert the data to a suitable format and wrap it into a CoglBitmap so that it can be passed to _cogl_texture_driver_upload_subregion_to_gl. This patch moves the common code to cogl-texture.c so that the virtual just takes a CoglBitmap that is already in the right format.
2010-07-08 10:15:22 -04:00
/* This should update the specified sub region of the texture with a
texture: Call _cogl_texture_prepare_for_upload in set_region impl 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>
2011-08-31 12:22:20 -04:00
sub region of the given bitmap. The bitmap is not converted
before being passed so the implementation is expected to call
_cogl_texture_prepare_for_upload with a suitable destination
format before uploading */
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
gboolean (* set_region) (CoglTexture *tex,
int src_x,
int src_y,
int dst_x,
int dst_y,
unsigned int dst_width,
unsigned int dst_height,
cogl-texture: Share the common code in the set_region virtual There was a lot of common code that was copied to all of the backends to convert the data to a suitable format and wrap it into a CoglBitmap so that it can be passed to _cogl_texture_driver_upload_subregion_to_gl. This patch moves the common code to cogl-texture.c so that the virtual just takes a CoglBitmap that is already in the right format.
2010-07-08 10:15:22 -04:00
CoglBitmap *bitmap);
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
cogl-texture: Share the common code in the get_data virtual Previously cogl_texture_get_data would pretty much directly pass on to the get_data texture virtual function. This ended up with a lot of common code that was copied to all of the backends. For example, the method is expected to return the required data size if the data pointer is NULL and to calculate its own rowstride if the rowstride is 0. Also it needs to convert the downloaded data if GL can't support that format directly. This patch moves the common code to cogl-texture.c so the virtual is always called with a format that can be downloaded directly by GL and with a valid rowstride. If the download fails then the virtual can return FALSE in which case cogl-texture will use the draw and read fallback.
2010-07-08 08:54:37 -04:00
/* This should copy the image data of the texture into @data. The
requested format will have been first passed through
Move the cogl texture driver functions to a vtable 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.
2011-07-07 07:48:24 -04:00
ctx->texture_driver->find_best_gl_get_data_format so it should
cogl-texture: Share the common code in the get_data virtual Previously cogl_texture_get_data would pretty much directly pass on to the get_data texture virtual function. This ended up with a lot of common code that was copied to all of the backends. For example, the method is expected to return the required data size if the data pointer is NULL and to calculate its own rowstride if the rowstride is 0. Also it needs to convert the downloaded data if GL can't support that format directly. This patch moves the common code to cogl-texture.c so the virtual is always called with a format that can be downloaded directly by GL and with a valid rowstride. If the download fails then the virtual can return FALSE in which case cogl-texture will use the draw and read fallback.
2010-07-08 08:54:37 -04:00
always be a format that is valid for GL (ie, no conversion should
be necessary). */
gboolean (* get_data) (CoglTexture *tex,
CoglPixelFormat format,
unsigned int rowstride,
guint8 *data);
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
void (* foreach_sub_texture_in_region) (CoglTexture *tex,
float virtual_tx_1,
float virtual_ty_1,
float virtual_tx_2,
float virtual_ty_2,
meta-texture: This publicly exposes CoglMetaTexture 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>
2011-10-08 09:13:03 -04:00
CoglMetaTextureCallback callback,
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
void *user_data);
cogl: improves header and coding style consistency 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.
2010-02-09 20:57:32 -05:00
int (* get_max_waste) (CoglTexture *tex);
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
gboolean (* is_sliced) (CoglTexture *tex);
gboolean (* can_hardware_repeat) (CoglTexture *tex);
void (* transform_coords_to_gl) (CoglTexture *tex,
float *s,
float *t);
Fix checks for out-of-bounds coordinates and repeats Add a return result from CoglTexture.transform_quad_coords_to_gl(), so that we can properly determine the nature of repeats in the face of GL_TEXTURE_RECTANGLE_ARB, where the returned coordinates are not normalized. The comment "We also work out whether any of the texture coordinates are outside the range [0.0,1.0]. We need to do this after calling transform_coords_to_gl in case the texture backend is munging the coordinates (such as in the sub texture backend)." is disregarded and removed, since it's actually the virtual coordinates that determine whether we repeat, not the GL coordinates. Warnings about disregarded layers are used in all cases where applicable, including for subtextures. http://bugzilla.openedhand.com/show_bug.cgi?id=2016 Signed-off-by: Neil Roberts <neil@linux.intel.com>
2010-03-01 16:49:04 -05:00
CoglTransformResult (* transform_quad_coords_to_gl) (CoglTexture *tex,
float *coords);
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
gboolean (* get_gl_texture) (CoglTexture *tex,
GLuint *out_gl_handle,
GLenum *out_gl_target);
void (* set_filters) (CoglTexture *tex,
GLenum min_filter,
GLenum mag_filter);
cogl-texture: Replace the ensure_mipmaps virtual with pre_paint Instead of the ensure_mipmaps virtual that is only called whenever the texture is about to be rendered with a min filter that needs the mipmap, there is now a pre_paint virtual that is always called when the texture is about to be painted in any way. It has a flags parameter which is used to specify whether the mipmap will be needed. This is useful for CoglTexturePixmapX11 because it needs to do stuff before painting that is unrelated to mipmapping.
2010-06-09 12:39:59 -04:00
void (* pre_paint) (CoglTexture *tex, CoglTexturePrePaintFlags flags);
cogl: Make CoglSubTexture only work for quad rendering The sub texture backend doesn't work well as a completely general texture backend because for example when rendering with cogl_polygon it needs to be able to tranform arbitrary texture coordinates without reference to the other coordintes. This can't be done when the texture coordinates are a multiple of one because sometimes the coordinate should represent the left or top edge and sometimes it should represent the bottom or top edge. For example if the s coordinates are 0 and 1 then 1 represents the right edge but if they are 1 and 2 then 1 represents the left edge. Instead the sub-textures are now documented not to support coordinates outside the range [0,1]. The coordinates for the sub-region are now represented as integers as this helps avoid rounding issues. The region can no longer be a super-region of the texture as this simplifies the code quite a lot. There are two new texture virtual functions: transform_quad_coords_to_gl - This transforms two pairs of coordinates representing a quad. It will return FALSE if the coordinates can not be transformed. The sub texture backend uses this to detect coordinates that require repeating which causes cogl-primitives to use manual repeating. ensure_non_quad_rendering - This is used in cogl_polygon and cogl_vertex_buffer to inform the texture backend that transform_quad_to_gl is going to be used. The atlas backend migrates the texture out of the atlas when it hits this.
2010-01-18 04:22:04 -05:00
void (* ensure_non_quad_rendering) (CoglTexture *tex);
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
Split the wrap mode of _cogl_texture_set_wrap_mode into three GL supports setting different wrap modes for the s, t and r coordinates so we should design the backend interface to support that also. The r coordinate is not currently used by any of the backends but we might as well have it to make life easier if we ever add support for 3D textures. http://bugzilla.openedhand.com/show_bug.cgi?id=2063
2010-03-25 13:29:22 -04:00
void (* set_wrap_mode_parameters) (CoglTexture *tex,
GLenum wrap_mode_s,
GLenum wrap_mode_t,
Rename the third texure coordinate from 'r' to 'p' Using 'r' to name the third component is problematic because that is commonly used to represent the red component of a vector representing a color. Under GLSL this is awkward because the texture swizzling for a vector uses a single letter for each component and the names for colors, textures and positions are synonymous. GLSL works around this by naming the components of the texture s, t, p and q. Cogl already effectively already exposes this naming because it exposes GLSL so it makes sense to use that naming consistently. Another alternative could be u, v and w. This is what Blender and Direct3D use. However the w component conflicts with the w component of a position vertex.
2010-07-12 12:01:32 -04:00
GLenum wrap_mode_p);
cogl: Move all of the fields from CoglTexture to CoglTexture2DSliced Most of the fields that were previously in CoglTexture are specific to the implementation of CoglTexture2DSliced so they should be placed there instead. For example, the 'mipmaps_dirty' flag is an implementation detail of the ensure_mipmaps function so it doesn't make sense to force all texture backends to have this function. Other fields such as width, height, gl_format and format may make sense for all textures but I've added them as virtual functions instead. This may make more sense for a sub-texture backend for example where it can calculate these based on the full texture.
2009-11-26 13:58:17 -05:00
CoglPixelFormat (* get_format) (CoglTexture *tex);
GLenum (* get_gl_format) (CoglTexture *tex);
cogl: improves header and coding style consistency 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.
2010-02-09 20:57:32 -05:00
int (* get_width) (CoglTexture *tex);
int (* get_height) (CoglTexture *tex);
material: Avoid redundant glBindTexture calls This adds a _cogl_bind_gl_texture_transient function that should be used instead of glBindTexture so we can have a consistent cache of the textures bound to each texture unit so we can avoid some redundant binding.
2010-04-26 05:01:43 -04:00
gboolean (* is_foreign) (CoglTexture *tex);
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
};
struct _CoglTexture
{
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
CoglObject _parent;
journal: Support per-framebuffer journals 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.
2011-01-06 08:25:45 -05:00
GList *framebuffers;
cogl: Use a vtable for the texture backends instead of a type and switch Instead of storing an enum with the backend type for each texture and then using a switch statement to decide which function to call, we should store pointers to all of the functions in a struct and have each texture point to that struct. This is potentially slightly faster when there are more backends and it makes implementing new backends easier because it's more obvious which functions have to be implemented.
2009-11-25 08:39:45 -05:00
const CoglTextureVtable *vtable;
};
material: Avoid redundant glBindTexture calls This adds a _cogl_bind_gl_texture_transient function that should be used instead of glBindTexture so we can have a consistent cache of the textures bound to each texture unit so we can avoid some redundant binding.
2010-04-26 05:01:43 -04:00
typedef enum _CoglTextureChangeFlags
{
/* Whenever the internals of a texture are changed such that the
* underlying GL textures that represent the CoglTexture change then
* we notify cogl-material.c via
cogl: rename CoglMaterial -> CoglPipeline 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.
2010-10-27 13:54:57 -04:00
* _cogl_pipeline_texture_pre_change_notify
material: Avoid redundant glBindTexture calls This adds a _cogl_bind_gl_texture_transient function that should be used instead of glBindTexture so we can have a consistent cache of the textures bound to each texture unit so we can avoid some redundant binding.
2010-04-26 05:01:43 -04:00
*/
COGL_TEXTURE_CHANGE_GL_TEXTURES
} CoglTextureChangeFlags;
Add a GL_GENERATE_MIPMAP fallback to the texture 2d and 3d backends The CoglTexture2DSliced backend has a fallback for when the framebuffer extension is missing so it's not possible to use glGenerateMipmap. This involves keeping a copy of the upper-left pixel of the tex image so that we can temporarily enable GL_GENERATE_MIPMAP on the texture object and do a sub texture update by reuploading the contents of the first pixel. This patch copies that mechanism to the 2D and 3D backends. The CoglTexturePixel structure which was previously internal to the sliced backend has been moved to cogl-texture-private.h so that it can be shared.
2010-07-13 13:41:01 -04:00
typedef struct _CoglTexturePixel CoglTexturePixel;
/* This is used by the texture backends to store the first pixel of
each GL texture. This is only used when glGenerateMipmap is not
available so that we can temporarily set GL_GENERATE_MIPMAP and
reupload a pixel */
struct _CoglTexturePixel
{
/* We need to store the format of the pixel because we store the
data in the source format which might end up being different for
each slice if a subregion is updated with a different format */
GLenum gl_format;
GLenum gl_type;
guint8 data[4];
};
journal: Support per-framebuffer journals 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.
2011-01-06 08:25:45 -05:00
void
_cogl_texture_init (CoglTexture *texture,
const CoglTextureVtable *vtable);
material: Avoid redundant glBindTexture calls This adds a _cogl_bind_gl_texture_transient function that should be used instead of glBindTexture so we can have a consistent cache of the textures bound to each texture unit so we can avoid some redundant binding.
2010-04-26 05:01:43 -04:00
void
_cogl_texture_free (CoglTexture *texture);
cogl-texture: List texture subclass types rather than hardcoding them Instead of having a hardcoded series of if-statements in cogl_is_texture to determine which types should appear as texture subclasses, they are now stored in a GSList attached to the Cogl context. The list is amended to using a new cogl_texture_register_type function. There is a convenience macro called COGL_TEXTURE_DEFINE which uses COGL_HANDLE_DEFINE_WITH_CODE to register the texture type when the _get_type() function is first called.
2010-06-11 08:50:36 -04:00
/* This is used to register a type to the list of handle types that
will be considered a texture in cogl_is_texture() */
void
_cogl_texture_register_texture_type (GQuark type);
#define COGL_TEXTURE_DEFINE(TypeName, type_name) \
COGL_HANDLE_DEFINE_WITH_CODE \
(TypeName, type_name, \
_cogl_texture_register_texture_type (_cogl_handle_ \
## type_name ## _get_type ()))
Don't define public cogl_is_* functions for internal types This adds a COGL_OBJECT_INTERNAL_DEFINE macro and friends that are the same as COGL_OBJECT_DEFINE except that they prefix the cogl_is_* function with an underscore so that it doesn't get exported in the shared library.
2010-07-09 13:46:31 -04:00
#define COGL_TEXTURE_INTERNAL_DEFINE(TypeName, type_name) \
COGL_HANDLE_INTERNAL_DEFINE_WITH_CODE \
(TypeName, type_name, \
_cogl_texture_register_texture_type (_cogl_handle_ \
## type_name ## _get_type ()))
[cogl-texture] Seal CoglTexture internals from cogl-primitives.c cogl-primitives.c was previously digging right into CoglTextures so it could manually iterate the texture slices for texturing quads and polygons and because we were missing some state getters we were lazily just poking into the structures directly. This adds some extra state getter functions, and adds a higher level _cogl_texture_foreach_slice () API that hopefully simplifies the way in which sliced textures may be used to render primitives. This lets you specify a rectangle in "virtual" texture coords and it will call a given callback for each slice that intersects that rectangle giving the virtual coords of the current slice and corresponding "real" texture coordinates for the underlying gl texture. At the same time a noteable bug in how we previously iterated sliced textures was fixed, whereby we weren't correctly handling inverted texture coordinates. E.g. with the previous code if you supplied texture coords of tx1=100,ty1=0,tx2=0,ty2=100 (inverted along y axis) that would result in a back-facing quad, which could be discarded if using back-face culling.
2009-09-16 06:56:17 -04:00
gboolean
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_can_hardware_repeat (CoglTexture *texture);
[cogl-texture] Seal CoglTexture internals from cogl-primitives.c cogl-primitives.c was previously digging right into CoglTextures so it could manually iterate the texture slices for texturing quads and polygons and because we were missing some state getters we were lazily just poking into the structures directly. This adds some extra state getter functions, and adds a higher level _cogl_texture_foreach_slice () API that hopefully simplifies the way in which sliced textures may be used to render primitives. This lets you specify a rectangle in "virtual" texture coords and it will call a given callback for each slice that intersects that rectangle giving the virtual coords of the current slice and corresponding "real" texture coordinates for the underlying gl texture. At the same time a noteable bug in how we previously iterated sliced textures was fixed, whereby we weren't correctly handling inverted texture coordinates. E.g. with the previous code if you supplied texture coords of tx1=100,ty1=0,tx2=0,ty2=100 (inverted along y axis) that would result in a back-facing quad, which could be discarded if using back-face culling.
2009-09-16 06:56:17 -04:00
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_transform_coords_to_gl (CoglTexture *texture,
[cogl-texture] Seal CoglTexture internals from cogl-primitives.c cogl-primitives.c was previously digging right into CoglTextures so it could manually iterate the texture slices for texturing quads and polygons and because we were missing some state getters we were lazily just poking into the structures directly. This adds some extra state getter functions, and adds a higher level _cogl_texture_foreach_slice () API that hopefully simplifies the way in which sliced textures may be used to render primitives. This lets you specify a rectangle in "virtual" texture coords and it will call a given callback for each slice that intersects that rectangle giving the virtual coords of the current slice and corresponding "real" texture coordinates for the underlying gl texture. At the same time a noteable bug in how we previously iterated sliced textures was fixed, whereby we weren't correctly handling inverted texture coordinates. E.g. with the previous code if you supplied texture coords of tx1=100,ty1=0,tx2=0,ty2=100 (inverted along y axis) that would result in a back-facing quad, which could be discarded if using back-face culling.
2009-09-16 06:56:17 -04:00
float *s,
float *t);
Fix checks for out-of-bounds coordinates and repeats Add a return result from CoglTexture.transform_quad_coords_to_gl(), so that we can properly determine the nature of repeats in the face of GL_TEXTURE_RECTANGLE_ARB, where the returned coordinates are not normalized. The comment "We also work out whether any of the texture coordinates are outside the range [0.0,1.0]. We need to do this after calling transform_coords_to_gl in case the texture backend is munging the coordinates (such as in the sub texture backend)." is disregarded and removed, since it's actually the virtual coordinates that determine whether we repeat, not the GL coordinates. Warnings about disregarded layers are used in all cases where applicable, including for subtextures. http://bugzilla.openedhand.com/show_bug.cgi?id=2016 Signed-off-by: Neil Roberts <neil@linux.intel.com>
2010-03-01 16:49:04 -05:00
CoglTransformResult
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_transform_quad_coords_to_gl (CoglTexture *texture,
cogl: Make CoglSubTexture only work for quad rendering The sub texture backend doesn't work well as a completely general texture backend because for example when rendering with cogl_polygon it needs to be able to tranform arbitrary texture coordinates without reference to the other coordintes. This can't be done when the texture coordinates are a multiple of one because sometimes the coordinate should represent the left or top edge and sometimes it should represent the bottom or top edge. For example if the s coordinates are 0 and 1 then 1 represents the right edge but if they are 1 and 2 then 1 represents the left edge. Instead the sub-textures are now documented not to support coordinates outside the range [0,1]. The coordinates for the sub-region are now represented as integers as this helps avoid rounding issues. The region can no longer be a super-region of the texture as this simplifies the code quite a lot. There are two new texture virtual functions: transform_quad_coords_to_gl - This transforms two pairs of coordinates representing a quad. It will return FALSE if the coordinates can not be transformed. The sub texture backend uses this to detect coordinates that require repeating which causes cogl-primitives to use manual repeating. ensure_non_quad_rendering - This is used in cogl_polygon and cogl_vertex_buffer to inform the texture backend that transform_quad_to_gl is going to be used. The atlas backend migrates the texture out of the atlas when it hits this.
2010-01-18 04:22:04 -05:00
float *coords);
[cogl-texture] Seal CoglTexture internals from cogl-primitives.c cogl-primitives.c was previously digging right into CoglTextures so it could manually iterate the texture slices for texturing quads and polygons and because we were missing some state getters we were lazily just poking into the structures directly. This adds some extra state getter functions, and adds a higher level _cogl_texture_foreach_slice () API that hopefully simplifies the way in which sliced textures may be used to render primitives. This lets you specify a rectangle in "virtual" texture coords and it will call a given callback for each slice that intersects that rectangle giving the virtual coords of the current slice and corresponding "real" texture coordinates for the underlying gl texture. At the same time a noteable bug in how we previously iterated sliced textures was fixed, whereby we weren't correctly handling inverted texture coordinates. E.g. with the previous code if you supplied texture coords of tx1=100,ty1=0,tx2=0,ty2=100 (inverted along y axis) that would result in a back-facing quad, which could be discarded if using back-face culling.
2009-09-16 06:56:17 -04:00
GLenum
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_get_gl_format (CoglTexture *texture);
[cogl-texture] Seal CoglTexture internals from cogl-primitives.c cogl-primitives.c was previously digging right into CoglTextures so it could manually iterate the texture slices for texturing quads and polygons and because we were missing some state getters we were lazily just poking into the structures directly. This adds some extra state getter functions, and adds a higher level _cogl_texture_foreach_slice () API that hopefully simplifies the way in which sliced textures may be used to render primitives. This lets you specify a rectangle in "virtual" texture coords and it will call a given callback for each slice that intersects that rectangle giving the virtual coords of the current slice and corresponding "real" texture coordinates for the underlying gl texture. At the same time a noteable bug in how we previously iterated sliced textures was fixed, whereby we weren't correctly handling inverted texture coordinates. E.g. with the previous code if you supplied texture coords of tx1=100,ty1=0,tx2=0,ty2=100 (inverted along y axis) that would result in a back-facing quad, which could be discarded if using back-face culling.
2009-09-16 06:56:17 -04:00
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_set_wrap_mode_parameters (CoglTexture *texture,
Split the wrap mode of _cogl_texture_set_wrap_mode into three GL supports setting different wrap modes for the s, t and r coordinates so we should design the backend interface to support that also. The r coordinate is not currently used by any of the backends but we might as well have it to make life easier if we ever add support for 3D textures. http://bugzilla.openedhand.com/show_bug.cgi?id=2063
2010-03-25 13:29:22 -04:00
GLenum wrap_mode_s,
GLenum wrap_mode_t,
Rename the third texure coordinate from 'r' to 'p' Using 'r' to name the third component is problematic because that is commonly used to represent the red component of a vector representing a color. Under GLSL this is awkward because the texture swizzling for a vector uses a single letter for each component and the names for colors, textures and positions are synonymous. GLSL works around this by naming the components of the texture s, t, p and q. Cogl already effectively already exposes this naming because it exposes GLSL so it makes sense to use that naming consistently. Another alternative could be u, v and w. This is what Blender and Direct3D use. However the w component conflicts with the w component of a position vertex.
2010-07-12 12:01:32 -04:00
GLenum wrap_mode_p);
Split the wrap mode of _cogl_texture_set_wrap_mode into three GL supports setting different wrap modes for the s, t and r coordinates so we should design the backend interface to support that also. The r coordinate is not currently used by any of the backends but we might as well have it to make life easier if we ever add support for 3D textures. http://bugzilla.openedhand.com/show_bug.cgi?id=2063
2010-03-25 13:29:22 -04:00
[cogl] Move rect and poly drawing code from cogl-texture.c to cogl-primitives.c None of this code directly related to implementing CoglTextures, and the code was needlessly duplicated between the GL and GLES backends. This moves the cogl_rectangle* and cogl_polygon* code into common/cogl-primitives.c makes which makes lot of sense since the two copies keep needlessly diverging introducing or fixing bugs in one but not the other. For instance I came accross one such bug regarding the enabling of texture units when unifying the code.
2009-03-23 08:29:15 -04:00
[cogl] Move the texture filters to be a property of the material layer The texture filters are now a property of the material layer rather than the texture object. Whenever a texture is painted with a material it sets the filters on all of the GL textures in the Cogl texture. The filter is cached so that it won't be changed unnecessarily. The automatic mipmap generation has changed so that the mipmaps are only generated when the texture is painted instead of every time the data changes. Changing the texture sets a flag to mark that the mipmaps are dirty. This works better if the FBO extension is available because we can use glGenerateMipmap. If the extension is not available it will temporarily enable automatic mipmap generation and reupload the first pixel of each slice. This requires tracking the data for the first pixel. The COGL_TEXTURE_AUTO_MIPMAP flag has been replaced with COGL_TEXTURE_NO_AUTO_MIPMAP so that it will default to auto-mipmapping. The mipmap generation is now effectively free if you are not using a mipmap filter mode so you would only want to disable it if you had some special reason to generate your own mipmaps. ClutterTexture no longer has to store its own copy of the filter mode. Instead it stores it in the material and the property is directly set and read from that. This fixes problems with the filters getting out of sync when a cogl handle is set on the texture directly. It also avoids the mess of having to rerealize the texture if the filter quality changes to HIGH because Cogl will take of generating the mipmaps if needed.
2009-06-04 11:04:57 -04:00
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_set_filters (CoglTexture *texture,
[cogl] Move the texture filters to be a property of the material layer The texture filters are now a property of the material layer rather than the texture object. Whenever a texture is painted with a material it sets the filters on all of the GL textures in the Cogl texture. The filter is cached so that it won't be changed unnecessarily. The automatic mipmap generation has changed so that the mipmaps are only generated when the texture is painted instead of every time the data changes. Changing the texture sets a flag to mark that the mipmaps are dirty. This works better if the FBO extension is available because we can use glGenerateMipmap. If the extension is not available it will temporarily enable automatic mipmap generation and reupload the first pixel of each slice. This requires tracking the data for the first pixel. The COGL_TEXTURE_AUTO_MIPMAP flag has been replaced with COGL_TEXTURE_NO_AUTO_MIPMAP so that it will default to auto-mipmapping. The mipmap generation is now effectively free if you are not using a mipmap filter mode so you would only want to disable it if you had some special reason to generate your own mipmaps. ClutterTexture no longer has to store its own copy of the filter mode. Instead it stores it in the material and the property is directly set and read from that. This fixes problems with the filters getting out of sync when a cogl handle is set on the texture directly. It also avoids the mess of having to rerealize the texture if the filter quality changes to HIGH because Cogl will take of generating the mipmaps if needed.
2009-06-04 11:04:57 -04:00
GLenum min_filter,
GLenum mag_filter);
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_pre_paint (CoglTexture *texture, CoglTexturePrePaintFlags flags);
[cogl] Move the texture filters to be a property of the material layer The texture filters are now a property of the material layer rather than the texture object. Whenever a texture is painted with a material it sets the filters on all of the GL textures in the Cogl texture. The filter is cached so that it won't be changed unnecessarily. The automatic mipmap generation has changed so that the mipmaps are only generated when the texture is painted instead of every time the data changes. Changing the texture sets a flag to mark that the mipmaps are dirty. This works better if the FBO extension is available because we can use glGenerateMipmap. If the extension is not available it will temporarily enable automatic mipmap generation and reupload the first pixel of each slice. This requires tracking the data for the first pixel. The COGL_TEXTURE_AUTO_MIPMAP flag has been replaced with COGL_TEXTURE_NO_AUTO_MIPMAP so that it will default to auto-mipmapping. The mipmap generation is now effectively free if you are not using a mipmap filter mode so you would only want to disable it if you had some special reason to generate your own mipmaps. ClutterTexture no longer has to store its own copy of the filter mode. Instead it stores it in the material and the property is directly set and read from that. This fixes problems with the filters getting out of sync when a cogl handle is set on the texture directly. It also avoids the mess of having to rerealize the texture if the filter quality changes to HIGH because Cogl will take of generating the mipmaps if needed.
2009-06-04 11:04:57 -04:00
cogl: Make CoglSubTexture only work for quad rendering The sub texture backend doesn't work well as a completely general texture backend because for example when rendering with cogl_polygon it needs to be able to tranform arbitrary texture coordinates without reference to the other coordintes. This can't be done when the texture coordinates are a multiple of one because sometimes the coordinate should represent the left or top edge and sometimes it should represent the bottom or top edge. For example if the s coordinates are 0 and 1 then 1 represents the right edge but if they are 1 and 2 then 1 represents the left edge. Instead the sub-textures are now documented not to support coordinates outside the range [0,1]. The coordinates for the sub-region are now represented as integers as this helps avoid rounding issues. The region can no longer be a super-region of the texture as this simplifies the code quite a lot. There are two new texture virtual functions: transform_quad_coords_to_gl - This transforms two pairs of coordinates representing a quad. It will return FALSE if the coordinates can not be transformed. The sub texture backend uses this to detect coordinates that require repeating which causes cogl-primitives to use manual repeating. ensure_non_quad_rendering - This is used in cogl_polygon and cogl_vertex_buffer to inform the texture backend that transform_quad_to_gl is going to be used. The atlas backend migrates the texture out of the atlas when it hits this.
2010-01-18 04:22:04 -05:00
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_ensure_non_quad_rendering (CoglTexture *texture);
cogl: Make CoglSubTexture only work for quad rendering The sub texture backend doesn't work well as a completely general texture backend because for example when rendering with cogl_polygon it needs to be able to tranform arbitrary texture coordinates without reference to the other coordintes. This can't be done when the texture coordinates are a multiple of one because sometimes the coordinate should represent the left or top edge and sometimes it should represent the bottom or top edge. For example if the s coordinates are 0 and 1 then 1 represents the right edge but if they are 1 and 2 then 1 represents the left edge. Instead the sub-textures are now documented not to support coordinates outside the range [0,1]. The coordinates for the sub-region are now represented as integers as this helps avoid rounding issues. The region can no longer be a super-region of the texture as this simplifies the code quite a lot. There are two new texture virtual functions: transform_quad_coords_to_gl - This transforms two pairs of coordinates representing a quad. It will return FALSE if the coordinates can not be transformed. The sub texture backend uses this to detect coordinates that require repeating which causes cogl-primitives to use manual repeating. ensure_non_quad_rendering - This is used in cogl_polygon and cogl_vertex_buffer to inform the texture backend that transform_quad_to_gl is going to be used. The atlas backend migrates the texture out of the atlas when it hits this.
2010-01-18 04:22:04 -05:00
cogl-texture: Split out _cogl_texture_prepare_for_upload The Cogl atlas code was using _cogl_texture_prepare_for_upload with a NULL pointer for the dst_bmp to determine the internal format of the texture without converting the bitmap. It needs to do this to decide whether the texture will go in the atlas before wasting time on the conversion. This use of the function is a little confusing so that part of it has been split out into a new function called _cogl_texture_determine_internal_format. The code to decide whether a premult conversion is needed has also been split out.
2010-02-03 17:54:44 -05:00
/* Utility function to determine which pixel format to use when
dst_format is COGL_PIXEL_FORMAT_ANY. If dst_format is not ANY then
it will just be returned directly */
CoglPixelFormat
_cogl_texture_determine_internal_format (CoglPixelFormat src_format,
CoglPixelFormat dst_format);
cogl: Let GL do the format conversion when uploading texture data Cogl accepts a pixel format for both the data in memory and the internal format to be used for the texture. If they do not match then it would convert them using the CoglBitmap functions before uploading the data. However, GL also lets you specify both formats so it makes more sense to let GL do the conversion. The driver may need the texture in a specific format so it may end up being converted anyway. The cogl_texture_upload_data functions have been removed and replaced with a single function to prepare the bitmap. This will only do the premultiplication conversion because that is the only part that GL can't do directly.
2010-02-01 07:11:58 -05:00
/* Utility function to help uploading a bitmap. If the bitmap needs
premult conversion then it will be copied and *copied_bitmap will
be set to TRUE. Otherwise dst_bmp will be set to a shallow copy of
src_bmp. The GLenums needed for uploading are returned */
cogl: Add a CoglTexture2D backend This is an optimised version of CoglTexture2DSliced that always deals with a single texture and always uses the GL_TEXTURE_2D target. cogl_texture_new_from_bitmap now tries to use this backend first. If it can't create a texture with that size then it falls back the sliced backend. cogl_texture_upload_data_prepare has been split into two functions because the sliced backend needs to know the real internal format before the conversion is performed. Otherwise the converted bitmap will be wasted if the backend can't support the size.
2009-11-27 13:45:36 -05:00
cogl-bitmap: Encapsulate the CoglBitmap even internally The CoglBitmap struct is now only defined within cogl-bitmap.c so that all of its members can now only be accessed with accessor functions. To get to the data pointer for the bitmap image you must first call _cogl_bitmap_map and later call _cogl_bitmap_unmap. The map function takes the same arguments as cogl_pixel_array_map so that eventually we can make a bitmap optionally internally divert to a pixel array. There is a _cogl_bitmap_new_from_data function which constructs a new bitmap object and takes ownership of the data pointer. The function gets passed a destroy callback which gets called when the bitmap is freed. This is similar to how gdk_pixbuf_new_from_data works. Alternatively NULL can be passed for the destroy function which means that the caller will manage the life of the pointer (but must guarantee that it stays alive at least until the bitmap is freed). This mechanism is used instead of the old approach of creating a CoglBitmap struct on the stack and manually filling in the members. It could also later be used to create a CoglBitmap that owns a GdkPixbuf ref so that we don't necessarily have to copy the GdkPixbuf data when converting to a bitmap. There is also _cogl_bitmap_new_shared. This creates a bitmap using a reference to another CoglBitmap for the data. This is a bit of a hack but it is needed by the atlas texture backend which wants to divert the set_region virtual to another texture but it needs to override the format of the bitmap to ignore the premult flag.
2010-07-07 13:44:16 -04:00
CoglBitmap *
cogl: Let GL do the format conversion when uploading texture data Cogl accepts a pixel format for both the data in memory and the internal format to be used for the texture. If they do not match then it would convert them using the CoglBitmap functions before uploading the data. However, GL also lets you specify both formats so it makes more sense to let GL do the conversion. The driver may need the texture in a specific format so it may end up being converted anyway. The cogl_texture_upload_data functions have been removed and replaced with a single function to prepare the bitmap. This will only do the premultiplication conversion because that is the only part that GL can't do directly.
2010-02-01 07:11:58 -05:00
_cogl_texture_prepare_for_upload (CoglBitmap *src_bmp,
CoglPixelFormat dst_format,
CoglPixelFormat *dst_format_out,
GLenum *out_glintformat,
GLenum *out_glformat,
GLenum *out_gltype);
[cogl-texture] Split CoglTexture into an abstract class + CoglTexture2dSliced cogl-texture-2d-sliced provides an implementation of CoglTexture and this seperation lays the foundation for potentially supporting atlas textures, pixmap textures (as in GLX_EXT_texture_from_pixmap) and fast-path GL_TEXTURE_{1D,2D,3D,RECTANGLE} textures in a maintainable fashion.
2009-08-30 06:36:11 -04:00
Improve cogl-texture maintainability by moving 90% into cogl/common This splits the limited components that differed between cogl/{gl,gles}/cogl-texture.c into new {gl,gles}/cogl-texture-driver.c files and the rest that can now be shared into cogl/common/cogl-texture.c
2009-07-27 19:37:11 -04:00
void
_cogl_texture_prep_gl_alignment_for_pixels_upload (int pixels_rowstride);
void
_cogl_texture_prep_gl_alignment_for_pixels_download (int pixels_rowstride);
cogl: Move data only used for upload out of CoglTexture The CoglTexture struct previously contained some fields which are only used to upload data such as the CoglBitmap and the source GL format. These are now moved to a separate CoglTextureUploadData struct which only exists for the duration of one of the cogl_texture_*_new functions. In cogl-texture there are utility functions which operate on this new struct rather than on CoglTexture directly. Some of the fields that were previously stored in the CoglBitmap struct are now copied to the CoglTexture such as the width, height, format and internal GL format. The rowstride was previously stored in CoglTexture and this was publicly accessible with the cogl_texture_get_rowstride function. However this doesn't seem to be a useful function because there is no need to use the same rowstride again when uploading or downloading new data. Instead cogl_texture_get_rowstride now just calculates a suitable rowstride from the format and width of the texture.
2009-11-26 12:32:52 -05:00
/* Utility function to use as a fallback for getting the data of any
texture via the framebuffer */
[cogl-texture] Split CoglTexture into an abstract class + CoglTexture2dSliced cogl-texture-2d-sliced provides an implementation of CoglTexture and this seperation lays the foundation for potentially supporting atlas textures, pixmap textures (as in GLX_EXT_texture_from_pixmap) and fast-path GL_TEXTURE_{1D,2D,3D,RECTANGLE} textures in a maintainable fashion.
2009-08-30 06:36:11 -04:00
gboolean
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_draw_and_read (CoglTexture *texture,
[cogl-texture] Split CoglTexture into an abstract class + CoglTexture2dSliced cogl-texture-2d-sliced provides an implementation of CoglTexture and this seperation lays the foundation for potentially supporting atlas textures, pixmap textures (as in GLX_EXT_texture_from_pixmap) and fast-path GL_TEXTURE_{1D,2D,3D,RECTANGLE} textures in a maintainable fashion.
2009-08-30 06:36:11 -04:00
CoglBitmap *target_bmp,
GLuint target_gl_format,
GLuint target_gl_type);
material: Avoid redundant glBindTexture calls This adds a _cogl_bind_gl_texture_transient function that should be used instead of glBindTexture so we can have a consistent cache of the textures bound to each texture unit so we can avoid some redundant binding.
2010-04-26 05:01:43 -04:00
gboolean
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_is_foreign (CoglTexture *texture);
material: Avoid redundant glBindTexture calls This adds a _cogl_bind_gl_texture_transient function that should be used instead of glBindTexture so we can have a consistent cache of the textures bound to each texture unit so we can avoid some redundant binding.
2010-04-26 05:01:43 -04:00
journal: Support per-framebuffer journals 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.
2011-01-06 08:25:45 -05:00
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_associate_framebuffer (CoglTexture *texture,
journal: Support per-framebuffer journals 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.
2011-01-06 08:25:45 -05:00
CoglFramebuffer *framebuffer);
const GList *
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_get_associated_framebuffers (CoglTexture *texture);
journal: Support per-framebuffer journals 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.
2011-01-06 08:25:45 -05:00
void
Add a strong CoglTexture type to replace CoglHandle 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>
2011-08-24 16:30:34 -04:00
_cogl_texture_flush_journal_rendering (CoglTexture *texture);
journal: Support per-framebuffer journals 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.
2011-01-06 08:25:45 -05:00
meta-texture: This publicly exposes CoglMetaTexture 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>
2011-10-08 09:13:03 -04:00
void
_cogl_texture_spans_foreach_in_region (CoglSpan *x_spans,
int n_x_spans,
CoglSpan *y_spans,
int n_y_spans,
CoglTexture **textures,
float *virtual_coords,
float x_normalize_factor,
float y_normalize_factor,
CoglPipelineWrapMode wrap_x,
CoglPipelineWrapMode wrap_y,
CoglMetaTextureCallback callback,
void *user_data);
Improve cogl-texture maintainability by moving 90% into cogl/common This splits the limited components that differed between cogl/{gl,gles}/cogl-texture.c into new {gl,gles}/cogl-texture-driver.c files and the rest that can now be shared into cogl/common/cogl-texture.c
2009-07-27 19:37:11 -04:00
#endif /* __COGL_TEXTURE_PRIVATE_H */
Reference in New Issue Copy Permalink