mutter/cogl-pango/cogl-pango-display-list.c

496 lines
16 KiB
C
Raw Normal View History

/*
* Clutter.
*
* An OpenGL based 'interactive canvas' library.
*
* Authored By Neil Roberts <neil@linux.intel.com>
*
* Copyright (C) 2009 Intel Corporation.
*
* 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
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <glib.h>
#include <cogl/cogl.h>
#include <string.h>
#include "cogl-pango-display-list.h"
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
#include "cogl-pango-pipeline-cache.h"
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
#include "cogl/cogl-context-private.h"
typedef enum
{
COGL_PANGO_DISPLAY_LIST_TEXTURE,
COGL_PANGO_DISPLAY_LIST_RECTANGLE,
COGL_PANGO_DISPLAY_LIST_TRAPEZOID
} CoglPangoDisplayListNodeType;
typedef struct _CoglPangoDisplayListNode CoglPangoDisplayListNode;
typedef struct _CoglPangoDisplayListRectangle CoglPangoDisplayListRectangle;
struct _CoglPangoDisplayList
{
CoglBool color_override;
CoglColor color;
GSList *nodes;
GSList *last_node;
CoglPangoPipelineCache *pipeline_cache;
};
/* This matches the format expected by cogl_rectangles_with_texture_coords */
struct _CoglPangoDisplayListRectangle
{
float x_1, y_1, x_2, y_2;
float s_1, t_1, s_2, t_2;
};
struct _CoglPangoDisplayListNode
{
CoglPangoDisplayListNodeType type;
CoglBool color_override;
CoglColor color;
CoglPipeline *pipeline;
union
{
struct
{
/* The texture to render these coords from */
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 20:30:34 +00:00
CoglTexture *texture;
/* Array of rectangles in the format expected by
cogl_rectangles_with_texture_coords */
GArray *rectangles;
/* A primitive representing those vertices */
CoglPrimitive *primitive;
} texture;
struct
{
float x_1, y_1;
float x_2, y_2;
} rectangle;
struct
{
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
CoglPrimitive *primitive;
} trapezoid;
} d;
};
CoglPangoDisplayList *
_cogl_pango_display_list_new (CoglPangoPipelineCache *pipeline_cache)
{
CoglPangoDisplayList *dl = g_slice_new0 (CoglPangoDisplayList);
dl->pipeline_cache = pipeline_cache;
return dl;
}
static void
_cogl_pango_display_list_append_node (CoglPangoDisplayList *dl,
CoglPangoDisplayListNode *node)
{
if (dl->last_node)
dl->last_node = dl->last_node->next = g_slist_prepend (NULL, node);
else
dl->last_node = dl->nodes = g_slist_prepend (NULL, node);
}
void
_cogl_pango_display_list_set_color_override (CoglPangoDisplayList *dl,
const CoglColor *color)
{
dl->color_override = TRUE;
dl->color = *color;
}
void
_cogl_pango_display_list_remove_color_override (CoglPangoDisplayList *dl)
{
dl->color_override = FALSE;
}
void
_cogl_pango_display_list_add_texture (CoglPangoDisplayList *dl,
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 20:30:34 +00:00
CoglTexture *texture,
float x_1, float y_1,
float x_2, float y_2,
float tx_1, float ty_1,
float tx_2, float ty_2)
{
CoglPangoDisplayListNode *node;
CoglPangoDisplayListRectangle *rectangle;
/* Add to the last node if it is a texture node with the same
target texture */
if (dl->last_node
&& (node = dl->last_node->data)->type == COGL_PANGO_DISPLAY_LIST_TEXTURE
&& node->d.texture.texture == texture
&& (dl->color_override
? (node->color_override && cogl_color_equal (&dl->color, &node->color))
: !node->color_override))
{
/* Get rid of the vertex buffer so that it will be recreated */
if (node->d.texture.primitive != NULL)
{
cogl_object_unref (node->d.texture.primitive);
node->d.texture.primitive = NULL;
}
}
else
{
/* Otherwise create a new node */
node = g_slice_new (CoglPangoDisplayListNode);
node->type = COGL_PANGO_DISPLAY_LIST_TEXTURE;
node->color_override = dl->color_override;
node->color = dl->color;
node->pipeline = NULL;
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 20:30:34 +00:00
node->d.texture.texture = cogl_object_ref (texture);
node->d.texture.rectangles
= g_array_new (FALSE, FALSE, sizeof (CoglPangoDisplayListRectangle));
node->d.texture.primitive = NULL;
_cogl_pango_display_list_append_node (dl, node);
}
g_array_set_size (node->d.texture.rectangles,
node->d.texture.rectangles->len + 1);
rectangle = &g_array_index (node->d.texture.rectangles,
CoglPangoDisplayListRectangle,
node->d.texture.rectangles->len - 1);
rectangle->x_1 = x_1;
rectangle->y_1 = y_1;
rectangle->x_2 = x_2;
rectangle->y_2 = y_2;
rectangle->s_1 = tx_1;
rectangle->t_1 = ty_1;
rectangle->s_2 = tx_2;
rectangle->t_2 = ty_2;
}
void
_cogl_pango_display_list_add_rectangle (CoglPangoDisplayList *dl,
float x_1, float y_1,
float x_2, float y_2)
{
CoglPangoDisplayListNode *node = g_slice_new (CoglPangoDisplayListNode);
node->type = COGL_PANGO_DISPLAY_LIST_RECTANGLE;
node->color_override = dl->color_override;
node->color = dl->color;
node->d.rectangle.x_1 = x_1;
node->d.rectangle.y_1 = y_1;
node->d.rectangle.x_2 = x_2;
node->d.rectangle.y_2 = y_2;
node->pipeline = NULL;
_cogl_pango_display_list_append_node (dl, node);
}
void
_cogl_pango_display_list_add_trapezoid (CoglPangoDisplayList *dl,
float y_1,
float x_11,
float x_21,
float y_2,
float x_12,
float x_22)
{
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
CoglContext *ctx = dl->pipeline_cache->ctx;
CoglPangoDisplayListNode *node = g_slice_new (CoglPangoDisplayListNode);
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
CoglVertexP2 vertices[4] = {
{ x_11, y_1 },
{ x_12, y_2 },
{ x_22, y_2 },
{ x_21, y_1 }
};
node->type = COGL_PANGO_DISPLAY_LIST_TRAPEZOID;
node->color_override = dl->color_override;
node->color = dl->color;
node->pipeline = NULL;
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
node->d.trapezoid.primitive =
cogl_primitive_new_p2 (ctx,
COGL_VERTICES_MODE_TRIANGLE_FAN,
4,
vertices);
_cogl_pango_display_list_append_node (dl, node);
}
static void
emit_rectangles_through_journal (CoglFramebuffer *fb,
CoglPipeline *pipeline,
CoglPangoDisplayListNode *node)
{
const float *rectangles = (const float *)node->d.texture.rectangles->data;
cogl_framebuffer_draw_textured_rectangles (fb,
pipeline,
rectangles,
node->d.texture.rectangles->len);
}
static void
emit_vertex_buffer_geometry (CoglFramebuffer *fb,
CoglPipeline *pipeline,
CoglPangoDisplayListNode *node)
{
CoglContext *ctx = fb->context;
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
/* It's expensive to go through the Cogl journal for large runs
* of text in part because the journal transforms the quads in software
* to avoid changing the modelview matrix. So for larger runs of text
* we load the vertices into a VBO, and this has the added advantage
* that if the text doesn't change from frame to frame the VBO can
* be re-used avoiding the repeated cost of validating the data and
* mapping it into the GPU... */
if (node->d.texture.primitive == NULL)
{
CoglAttributeBuffer *buffer;
CoglVertexP2T2 *verts, *v;
int n_verts;
CoglBool allocated = FALSE;
CoglAttribute *attributes[2];
CoglPrimitive *prim;
int i;
n_verts = node->d.texture.rectangles->len * 4;
buffer
Allow propogation of OOM errors to apps This allows apps to catch out-of-memory errors when allocating textures. Textures can be pretty huge at times and so it's quite possible for an application to try and allocate more memory than is available. It's also very possible that the application can take some action in response to reduce memory pressure (such as freeing up texture caches perhaps) so we shouldn't just automatically abort like we do for trivial heap allocations. These public functions now take a CoglError argument so applications can catch out of memory errors: cogl_buffer_map cogl_buffer_map_range cogl_buffer_set_data cogl_framebuffer_read_pixels_into_bitmap cogl_pixel_buffer_new cogl_texture_new_from_data cogl_texture_new_from_bitmap Note: we've been quite conservative with how many apis we let throw OOM CoglErrors since we don't really want to put a burdon on developers to be checking for errors with every cogl api call. So long as there is some lower level api for apps to use that let them catch OOM errors for everything necessary that's enough and we don't have to make more convenient apis more awkward to use. The main focus is on bitmaps and texture allocations since they can be particularly large and prone to failing. A new cogl_attribute_buffer_new_with_size() function has been added in case developers need to catch OOM errors when allocating attribute buffers whereby they can first use _buffer_new_with_size() (which doesn't take a CoglError) followed by cogl_buffer_set_data() which will lazily allocate the buffer storage and report OOM errors. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit f7735e141ad537a253b02afa2a8238f96340b978) Note: since we can't break the API for Cogl 1.x then actually the main purpose of cherry picking this patch is to keep in-line with changes on the master branch so that we can easily cherry-pick patches. All the api changes relating stable apis released on the 1.12 branch have been reverted as part of cherry-picking this patch so this most just applies all the internal plumbing changes that enable us to correctly propagate OOM errors.
2012-11-08 17:54:10 +00:00
= cogl_attribute_buffer_new_with_size (ctx,
n_verts *
sizeof (CoglVertexP2T2));
if ((verts = cogl_buffer_map (COGL_BUFFER (buffer),
COGL_BUFFER_ACCESS_WRITE,
COGL_BUFFER_MAP_HINT_DISCARD)) == NULL)
{
verts = g_new (CoglVertexP2T2, n_verts);
allocated = TRUE;
}
v = verts;
/* Copy the rectangles into the buffer and expand into four
vertices instead of just two */
for (i = 0; i < node->d.texture.rectangles->len; i++)
{
const CoglPangoDisplayListRectangle *rectangle
= &g_array_index (node->d.texture.rectangles,
CoglPangoDisplayListRectangle, i);
v->x = rectangle->x_1;
v->y = rectangle->y_1;
v->s = rectangle->s_1;
v->t = rectangle->t_1;
v++;
v->x = rectangle->x_1;
v->y = rectangle->y_2;
v->s = rectangle->s_1;
v->t = rectangle->t_2;
v++;
v->x = rectangle->x_2;
v->y = rectangle->y_2;
v->s = rectangle->s_2;
v->t = rectangle->t_2;
v++;
v->x = rectangle->x_2;
v->y = rectangle->y_1;
v->s = rectangle->s_2;
v->t = rectangle->t_1;
v++;
}
if (allocated)
{
cogl_buffer_set_data (COGL_BUFFER (buffer),
0, /* offset */
verts,
sizeof (CoglVertexP2T2) * n_verts);
g_free (verts);
}
else
cogl_buffer_unmap (COGL_BUFFER (buffer));
attributes[0] = cogl_attribute_new (buffer,
"cogl_position_in",
sizeof (CoglVertexP2T2),
G_STRUCT_OFFSET (CoglVertexP2T2, x),
2, /* n_components */
COGL_ATTRIBUTE_TYPE_FLOAT);
attributes[1] = cogl_attribute_new (buffer,
"cogl_tex_coord0_in",
sizeof (CoglVertexP2T2),
G_STRUCT_OFFSET (CoglVertexP2T2, s),
2, /* n_components */
COGL_ATTRIBUTE_TYPE_FLOAT);
prim = cogl_primitive_new_with_attributes (COGL_VERTICES_MODE_TRIANGLES,
n_verts,
attributes,
2 /* n_attributes */);
#ifdef CLUTTER_COGL_HAS_GL
Add a GL 3 driver This adds a new CoglDriver for GL 3 called COGL_DRIVER_GL3. When requested, the GLX, EGL and SDL2 winsyss will set the necessary attributes to request a forward-compatible core profile 3.1 context. That means it will have no deprecated features. To simplify the explosion of checks for specific combinations of context->driver, many of these conditionals have now been replaced with private feature flags that are checked instead. The GL and GLES drivers now initialise these private feature flags depending on which driver is used. The fixed function backends now explicitly check whether the fixed function private feature is available which means the GL3 driver will fall back to always using the GLSL progend. Since Rob's latest patches the GLSL progend no longer uses any fixed function API anyway so it should just work. The driver is currently lower priority than COGL_DRIVER_GL so it will not be used unless it is specificly requested. We may want to change this priority at some point because apparently Mesa can make some memory savings if a core profile context is used. In GL 3, getting the combined extensions string with glGetString is deprecated so this patch changes it to use glGetStringi to build up an array of extensions instead. _cogl_context_get_gl_extensions now returns this array instead of trying to return a const string. The caller is expected to free the array. Some issues with this patch: • GL 3 does not support GL_ALPHA format textures. We should probably make this a feature flag or something. Cogl uses this to render text which currently just throws a GL error and breaks so it's pretty important to do something about this before considering the GL3 driver to be stable. • GL 3 doesn't support client side vertex buffers. This probably doesn't matter because CoglBuffer won't normally use malloc'd buffers if VBOs are available, but it might but worth making malloc'd buffers a private feature and forcing it not to use them. • GL 3 doesn't support the default vertex array object. This patch just makes it create and bind a single non-default vertex array object which gets used just like the normal default object. Ideally it would be good to use vertex array objects properly and attach them to a CoglPrimitive to cache the state. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 66c9db993595b3a22e63f4c201ea468bc9b88cb6)
2012-09-26 19:32:36 +00:00
if ((ctx->private_feature_flags & COGL_PRIVATE_FEATURE_QUADS))
cogl_primitive_set_mode (prim, GL_QUADS);
else
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
#endif
{
/* GLES doesn't support GL_QUADS so instead we use a VBO
with indexed vertices to generate GL_TRIANGLES from the
quads */
CoglIndices *indices =
cogl_get_rectangle_indices (ctx, node->d.texture.rectangles->len);
cogl_primitive_set_indices (prim, indices,
node->d.texture.rectangles->len * 6);
}
node->d.texture.primitive = prim;
cogl_object_unref (buffer);
cogl_object_unref (attributes[0]);
cogl_object_unref (attributes[1]);
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 19:44:56 +00:00
}
Add _primitive_draw to replace _framebuffer_draw_primitive When splitting out the CoglPath api we saw that we would be left with inconsistent drawing apis if the drawing apis in core Cogl were lumped into the cogl_framebuffer_ api considering other Cogl sub-libraries or that others will want to create higher level drawing apis outside of Cogl but can't use the same namespace. So that we can aim for a more consistent style this adds a cogl_primitive_draw() api, comparable to cogl_path_fill() or cogl_pango_show_layout() that's intended to replace cogl_framebuffer_draw_primitive() Note: the attribute and rectangle drawing apis are still in the cogl_framebuffer_ namespace and this might potentially change but in these cases there is no single object representing the thing being drawn so it seems a more reasonable they they live in the framebuffer namespace for now. Note: the cogl_framebuffer_draw_primitive() api isn't removed by this patch so it can more conveniently be cherry picked to the 1.16 branch so we can mark it deprecated for a short while. Even though it's marked as experimental api we know that there are people using the api so we'd like to give them a chance to switch to the new api. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 418912b93ff81a47f9b38114d05335ab76277c48) Conflicts: cogl-pango/cogl-pango-display-list.c cogl/Makefile.am cogl/cogl-framebuffer.c cogl/cogl-pipeline-layer-state.h cogl/cogl2-path.c cogl/driver/gl/cogl-clip-stack-gl.c
2013-07-09 22:47:29 +00:00
cogl_primitive_draw (node->d.texture.primitive,
fb,
pipeline);
}
static void
_cogl_framebuffer_draw_display_list_texture (CoglFramebuffer *fb,
CoglPipeline *pipeline,
CoglPangoDisplayListNode *node)
{
/* For small runs of text like icon labels, we can get better performance
* going through the Cogl journal since text may then be batched together
* with other geometry. */
/* FIXME: 25 is a number I plucked out of thin air; it would be good
* to determine this empirically! */
if (node->d.texture.rectangles->len < 25)
emit_rectangles_through_journal (fb, pipeline, node);
else
emit_vertex_buffer_geometry (fb, pipeline, node);
}
void
_cogl_pango_display_list_render (CoglFramebuffer *fb,
CoglPangoDisplayList *dl,
const CoglColor *color)
{
GSList *l;
for (l = dl->nodes; l; l = l->next)
{
CoglPangoDisplayListNode *node = l->data;
CoglColor draw_color;
if (node->pipeline == NULL)
{
if (node->type == COGL_PANGO_DISPLAY_LIST_TEXTURE)
node->pipeline =
_cogl_pango_pipeline_cache_get (dl->pipeline_cache,
node->d.texture.texture);
else
node->pipeline =
_cogl_pango_pipeline_cache_get (dl->pipeline_cache,
NULL);
}
if (node->color_override)
/* Use the override color but preserve the alpha from the
draw color */
cogl_color_init_from_4ub (&draw_color,
cogl_color_get_red_byte (&node->color),
cogl_color_get_green_byte (&node->color),
cogl_color_get_blue_byte (&node->color),
cogl_color_get_alpha_byte (color));
else
draw_color = *color;
cogl_color_premultiply (&draw_color);
cogl_pipeline_set_color (node->pipeline, &draw_color);
switch (node->type)
{
case COGL_PANGO_DISPLAY_LIST_TEXTURE:
_cogl_framebuffer_draw_display_list_texture (fb, node->pipeline, node);
break;
case COGL_PANGO_DISPLAY_LIST_RECTANGLE:
cogl_framebuffer_draw_rectangle (fb,
node->pipeline,
node->d.rectangle.x_1,
node->d.rectangle.y_1,
node->d.rectangle.x_2,
node->d.rectangle.y_2);
break;
case COGL_PANGO_DISPLAY_LIST_TRAPEZOID:
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
cogl_framebuffer_draw_primitive (fb, node->pipeline,
node->d.trapezoid.primitive);
break;
}
}
}
static void
_cogl_pango_display_list_node_free (CoglPangoDisplayListNode *node)
{
if (node->type == COGL_PANGO_DISPLAY_LIST_TEXTURE)
{
g_array_free (node->d.texture.rectangles, TRUE);
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 20:30:34 +00:00
if (node->d.texture.texture != NULL)
cogl_object_unref (node->d.texture.texture);
if (node->d.texture.primitive != NULL)
cogl_object_unref (node->d.texture.primitive);
}
Separate out CoglPath api into sub-library This splits out the cogl_path_ api into a separate cogl-path sub-library like cogl-pango and cogl-gst. This enables developers to build Cogl with this sub-library disabled if they don't need it which can be useful when its important to keep the size of an application and its dependencies down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path have been renamed to cogl_path_{fill,stroke}. There were a few places in core cogl and cogl-gst that referenced the CoglPath api and these have been decoupled by using the CoglPrimitive api instead. In the case of cogl_framebuffer_push_path_clip() the core clip stack no longer accepts path clips directly but it's now possible to get a CoglPrimitive for the fill of a path and so the implementation of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as a shim that first gets a CoglPrimitive and uses cogl_framebuffer_push_primitive_clip instead. We may want to consider renaming cogl_framebuffer_push_path_clip to put it in the cogl_path_ namespace. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f) So as to avoid breaking the 1.x API or even the ABI since we are quite late in the 1.16 development cycle the patch was modified to build cogl-path as a noinst_LTLIBRARY before building cogl and link the code directly into libcogl.so as it was previously. This way we can wait until the start of the 1.18 cycle before splitting the code into a separate libcogl-path.so. This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid breaking the 1.x API/ABI.
2013-04-28 02:22:24 +00:00
else if (node->type == COGL_PANGO_DISPLAY_LIST_TRAPEZOID)
cogl_object_unref (node->d.trapezoid.primitive);
if (node->pipeline)
cogl_object_unref (node->pipeline);
g_slice_free (CoglPangoDisplayListNode, node);
}
void
_cogl_pango_display_list_clear (CoglPangoDisplayList *dl)
{
g_slist_foreach (dl->nodes, (GFunc) _cogl_pango_display_list_node_free, NULL);
g_slist_free (dl->nodes);
dl->nodes = NULL;
dl->last_node = NULL;
}
void
_cogl_pango_display_list_free (CoglPangoDisplayList *dl)
{
_cogl_pango_display_list_clear (dl);
g_slice_free (CoglPangoDisplayList, dl);
}