isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-22 16:10:41 -05:00
Code Issues Packages Projects Releases Wiki Activity
c8aae9a663
mutter/cogl/cogl-path-private.h

99 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
#include "cogl-handle.h"
#define COGL_PATH(tex) ((CoglPath *)(tex))
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
{
CoglHandleObject _parent;
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
CoglPathData *data;
};
struct _CoglPathData
{
unsigned int ref_count;
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
GArray *path_nodes;
floatVec2 path_start;
floatVec2 path_pen;
unsigned int last_path;
floatVec2 path_nodes_min;
floatVec2 path_nodes_max;
};
/* This is an internal version of cogl_path_new that doesn't affect
the current path and just creates a new handle */
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
CoglPath *
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_new (void);
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