isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-26 01:50:42 -05:00
Code Issues Packages Projects Releases Wiki Activity
992d5f7fb6
mutter/cogl/cogl-path-private.h

93 lines
2.0 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;
typedef struct _CoglPath CoglPath;
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 */
CoglHandle
_cogl_path_new (void);
void
_cogl_add_path_to_stencil_buffer (CoglHandle path,
gboolean merge,
gboolean need_clear);
#endif /* __COGL_PATH_PRIVATE_H */
Reference in New Issue Copy Permalink