brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7379a5fc04
mutter/cogl/cogl-path-private.h

101 lines
2.2 KiB
C
Raw Normal View History

cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2010 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/>.
*
*
*/
#ifndef __COGL_PATH_PRIVATE_H
#define __COGL_PATH_PRIVATE_H
path 2.0: update path API for experimental 2.0 API When COGL_ENABLE_EXPERIMENTAL_2_0_API is defined cogl.h will now include cogl2-path.h which changes cogl_path_new() so it can directly return a CoglPath pointer; it no longer exposes a prototype for cogl_{get,set}_path and all the remaining cogl_path_ functions now take an explicit path as their first argument. The idea is that we want to encourage developers to retain path objects for as long as possible so they can take advantage of us uploading the path geometry to the GPU. Currently although it is possible to start a new path and query the current path, it is not convenient. The other thing is that we want to get Cogl to the point where nothing depends on a global, current context variable. This will allow us to one day define a sensible threading model if/when that is ever desired.
2010-11-03 20:27:47 -04:00
#include "cogl-object.h"
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
typedef struct _floatVec2
{
float x;
float y;
} floatVec2;
typedef struct _CoglPathNode
{
float x;
float y;
unsigned int path_size;
} CoglPathNode;
typedef struct _CoglBezQuad
{
floatVec2 p1;
floatVec2 p2;
floatVec2 p3;
} CoglBezQuad;
typedef struct _CoglBezCubic
{
floatVec2 p1;
floatVec2 p2;
floatVec2 p3;
floatVec2 p4;
} CoglBezCubic;
cogl-path: Use true copy-on-write semantics Previously a path copy was implemented such that only the array of path nodes was shared with the source and the rest of the data is copied. This was so that the copy could avoid a deep copy if the source path is appended to because the copy keeps track of its own length. This optimisation is probably not worthwhile because it makes the copies less cheap. Instead the CoglPath struct now just contains a single pointer to a new CoglPathData struct which is separately ref-counted. When the path is modified it will be copied if the ref count on the data is not 1.
2010-04-22 06:58:52 -04:00
typedef struct _CoglPathData CoglPathData;
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
struct _CoglPath
{
path 2.0: update path API for experimental 2.0 API When COGL_ENABLE_EXPERIMENTAL_2_0_API is defined cogl.h will now include cogl2-path.h which changes cogl_path_new() so it can directly return a CoglPath pointer; it no longer exposes a prototype for cogl_{get,set}_path and all the remaining cogl_path_ functions now take an explicit path as their first argument. The idea is that we want to encourage developers to retain path objects for as long as possible so they can take advantage of us uploading the path geometry to the GPU. Currently although it is possible to start a new path and query the current path, it is not convenient. The other thing is that we want to get Cogl to the point where nothing depends on a global, current context variable. This will allow us to one day define a sensible threading model if/when that is ever desired.
2010-11-03 20:27:47 -04:00
CoglObject _parent;
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
path 2.0: update path API for experimental 2.0 API When COGL_ENABLE_EXPERIMENTAL_2_0_API is defined cogl.h will now include cogl2-path.h which changes cogl_path_new() so it can directly return a CoglPath pointer; it no longer exposes a prototype for cogl_{get,set}_path and all the remaining cogl_path_ functions now take an explicit path as their first argument. The idea is that we want to encourage developers to retain path objects for as long as possible so they can take advantage of us uploading the path geometry to the GPU. Currently although it is possible to start a new path and query the current path, it is not convenient. The other thing is that we want to get Cogl to the point where nothing depends on a global, current context variable. This will allow us to one day define a sensible threading model if/when that is ever desired.
2010-11-03 20:27:47 -04:00
CoglPathData *data;
cogl-path: Use true copy-on-write semantics Previously a path copy was implemented such that only the array of path nodes was shared with the source and the rest of the data is copied. This was so that the copy could avoid a deep copy if the source path is appended to because the copy keeps track of its own length. This optimisation is probably not worthwhile because it makes the copies less cheap. Instead the CoglPath struct now just contains a single pointer to a new CoglPathData struct which is separately ref-counted. When the path is modified it will be copied if the ref count on the data is not 1.
2010-04-22 06:58:52 -04:00
};
cogl-path: Use the vertex array API instead of CoglVertexBuffer The new vertex array is now implemented in terms of the CoglVertexBuffer anyway so it should be slightly faster to use a vertex array directly.
2010-11-03 11:48:56 -04:00
#define COGL_PATH_N_ATTRIBUTES 2
cogl-path: Use true copy-on-write semantics Previously a path copy was implemented such that only the array of path nodes was shared with the source and the rest of the data is copied. This was so that the copy could avoid a deep copy if the source path is appended to because the copy keeps track of its own length. This optimisation is probably not worthwhile because it makes the copies less cheap. Instead the CoglPath struct now just contains a single pointer to a new CoglPathData struct which is separately ref-counted. When the path is modified it will be copied if the ref count on the data is not 1.
2010-04-22 06:58:52 -04:00
struct _CoglPathData
{
cogl-path: Use the vertex array API instead of CoglVertexBuffer The new vertex array is now implemented in terms of the CoglVertexBuffer anyway so it should be slightly faster to use a vertex array directly.
2010-11-03 11:48:56 -04:00
unsigned int ref_count;
cogl-path: Use true copy-on-write semantics Previously a path copy was implemented such that only the array of path nodes was shared with the source and the rest of the data is copied. This was so that the copy could avoid a deep copy if the source path is appended to because the copy keeps track of its own length. This optimisation is probably not worthwhile because it makes the copies less cheap. Instead the CoglPath struct now just contains a single pointer to a new CoglPathData struct which is separately ref-counted. When the path is modified it will be copied if the ref count on the data is not 1.
2010-04-22 06:58:52 -04:00
cogl-path: Use the vertex array API instead of CoglVertexBuffer The new vertex array is now implemented in terms of the CoglVertexBuffer anyway so it should be slightly faster to use a vertex array directly.
2010-11-03 11:48:56 -04:00
CoglPathFillRule fill_rule;
cogl-path: Allow changing the fill rule This adds two new API calls- cogl_path_set_fill_rule and cogl_path_get_fill_rule. This allows modifying the fill rule of the current path. In addition to the previous default fill rule of 'even-odd' it now supports the 'non-zero' rule. The fill rule is a property of the path (not the Cogl context) so creating a new path or preserving a path with cogl_path_get_handle affects the fill rule.
2010-06-23 08:40:43 -04:00
cogl-path: Use the vertex array API instead of CoglVertexBuffer The new vertex array is now implemented in terms of the CoglVertexBuffer anyway so it should be slightly faster to use a vertex array directly.
2010-11-03 11:48:56 -04:00
GArray *path_nodes;
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
cogl-path: Use the vertex array API instead of CoglVertexBuffer The new vertex array is now implemented in terms of the CoglVertexBuffer anyway so it should be slightly faster to use a vertex array directly.
2010-11-03 11:48:56 -04:00
floatVec2 path_start;
floatVec2 path_pen;
unsigned int last_path;
floatVec2 path_nodes_min;
floatVec2 path_nodes_max;
cogl-path: Use the GLU tesselator to draw paths Instead of drawing paths using the stencil buffer trick, it now tesselates the path into triangles using the GLU tesselator and renders them directly. A vbo is created with one vertex for each node on the path. The tesselator is used to generate a series of indices into the vbo as triangles. The tesselator's output of strips and fans is converted into GL_TRIANGLES so that it can be rendered with a single draw call (but the vertices are still shared via the indices). The vbo is stored with the path so that if the application uses retained paths then Cogl won't have to tessellate again. The vertices also have texture coordinates associated with them so that it can replicate the old behaviour of drawing a material with a texture by fitting the texture to the bounding box of the path and then clipping it. However if the texture contains waste or is sliced then the vertex buffer code will refuse to draw it. In this case it will revert back to drawing the path into the stencil buffer and then drawing the material as a clipped quad. The VBO is used even when setting up the stencil buffer for clipping to a path because the tessellated geometry may cover less area. The old scanline rasterizer has been removed because the tesselator should work equally well on drivers with no stencil buffer.
2010-04-15 18:56:46 -04:00
cogl-path: Use the vertex array API instead of CoglVertexBuffer The new vertex array is now implemented in terms of the CoglVertexBuffer anyway so it should be slightly faster to use a vertex array directly.
2010-11-03 11:48:56 -04:00
CoglVertexArray *vbo;
CoglIndices *vbo_indices;
unsigned int vbo_n_indices;
CoglVertexAttribute *vbo_attributes[COGL_PATH_N_ATTRIBUTES + 1];
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
};
void
path: Remove use of CoglHandle in the CoglPath API This replaces the use of CoglHandle with strongly type CoglPath * pointers instead. The only function not converted for now is cogl_is_path which will be done in a later commit.
2010-05-27 19:35:47 -04:00
_cogl_add_path_to_stencil_buffer (CoglPath *path,
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
gboolean merge,
gboolean need_clear);
cogl-path: Export _cogl_path_get_bounds _cogl_path_get_bounds is no longer static and is exported in cogl-path-private.h so that it can be used in the clip stack code. The old version of the function returned x/y and width/height. However this was mostly used to call cogl_rectangle which takes x1/y1 x2/y2. The function has been changed to just directly return the second form because it is more useful. Anywhere that was previously using the function now just directly looks at path->path_nodes_min and path->path_nodes_max instead.
2010-04-22 09:13:52 -04:00
void
_cogl_path_get_bounds (CoglPath *path,
float *min_x,
float *min_y,
float *max_x,
float *max_y);
cogl: Support retained paths This adds three new API calls: CoglHandle cogl_path_get() void cogl_path_set(CoglHandle path) CoglHandle cogl_path_copy(CoglHandle path) All of the fields relating to the path have been moved from the Cogl context to a new CoglPath handle type. The cogl context now just contains a CoglPath handle. All of the existing path commands manipulate the data in the current path handle. cogl_path_new now just creates a new path handle and unrefs the old one. The path handle can be stored for later with cogl_path_get. The path can then be copied with cogl_path_copy. Internally it implements copy-on-write semantics with an extra optimisation that it will only copy the data if the new path is modified, but not if the original path is modified. It can do this because the only way to modify a path is by appending to it so the copied path is able to store its own path length and only render the nodes up to that length. For this to work the copied path also needs to keep its own copies of the path extents because the parent path may change these by adding nodes. The clip stack now uses the cogl_path_copy mechanism to store paths in the stack instead of directly copying the data. This should save some memory and processing time.
2010-04-08 12:43:27 -04:00
#endif /* __COGL_PATH_PRIVATE_H */
Reference in New Issue Copy Permalink