sungmg/mutter-performance-source
1
0
Fork 0
Code Activity
mutter-performance-source/cogl/cogl-path/cogl-path-private.h

127 lines
3.3 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 16:43:27 +00:00
/*
* Cogl
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-22 01:28:54 +00:00
* A Low Level GPU Graphics and Utilities API
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 16:43:27 +00:00
*
* Copyright (C) 2010 Intel Corporation.
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-22 01:28:54 +00:00
* Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use, copy,
* modify, merge, publish, distribute, sublicense, and/or sell copies
* of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
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 16:43:27 +00:00
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-22 01:28:54 +00:00
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
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 16:43:27 +00:00
*
This re-licenses Cogl 1.18 under the MIT license Since the Cogl 1.18 branch is actively maintained in parallel with the master branch; this is a counter part to commit 1b83ef938fc16b which re-licensed the master branch to use the MIT license. This re-licensing is a follow up to the proposal that was sent to the Cogl mailing list: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license. This patch was not simply cherry-picked from master; but the same methodology was used to check the source files.
2014-02-22 01:28:54 +00:00
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
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 16:43:27 +00:00
*
*
*/
#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-04 00:27:47 +00:00
#include "cogl-object.h"
path: handle slice tex fallback using clip stack If we are asked to fill a path using any sliced textures then we need to fallback to adding a mask of the path to the stencil buffer and then drawing a bounding rectangle with the source textures instead. Previously we were sharing some of the clip-stack code for adding the path mask to the stencil buffer and being careful to check that the current clip stack has been flushed already. We then made sure to dirty the clip stack to be sure the path mask would be cleared from the stencil buffer later. This patch aims to simplify how this fallback is dealt with by just using the public clipping API instead of relying on more fiddly tricks to modify the stencil buffer directly without conflicting with the clip stack. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-10-01 17:40:10 +00:00
#include "cogl-attribute-private.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 16:43:27 +00: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 10:58:52 +00: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 16:43:27 +00: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-04 00:27:47 +00: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 16:43:27 +00: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-04 00:27:47 +00: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 10:58:52 +00: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 15:48:56 +00: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 10:58:52 +00: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 15:48:56 +00: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 10:58:52 +00:00
Add a context member to CoglPath cogl_path_new now takes a CoglContext pointer which it keeps a pointer to instead of relying on the global context. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit afc63f8211c230f8fd1f7801f9085627c46a8661) Since we can't change the api on this branch this just applies the internal cleanups so we depend less on _COGL_GET_CONTEXT
2012-04-16 12:21:15 +00:00
CoglContext *context;
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 15:48:56 +00: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 12:40:43 +00: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 15:48:56 +00: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 16:43:27 +00: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 15:48:56 +00: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 22:56:46 +00:00
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 15:01:41 +00:00
CoglAttributeBuffer *fill_attribute_buffer;
cogl-path: Stroke using the vertex attribute API Previously when stroking a path it was flushing a pipeline and then directly calling glDrawArrays to draw the line strip from the path nodes array. This patch changes it to build a CoglVertexArray and a series of attributes to paint with instead. The vertex array and attributes are attached to the CoglPath so it can be reused later. The old vertex array for filling has been renamed to fill_vbo.
2010-12-03 11:31:09 +00:00
CoglIndices *fill_vbo_indices;
unsigned int fill_vbo_n_indices;
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 15:01:41 +00:00
CoglAttribute *fill_attributes[COGL_PATH_N_ATTRIBUTES + 1];
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 *fill_primitive;
cogl-path: Stroke using the vertex attribute API Previously when stroking a path it was flushing a pipeline and then directly calling glDrawArrays to draw the line strip from the path nodes array. This patch changes it to build a CoglVertexArray and a series of attributes to paint with instead. The vertex array and attributes are attached to the CoglPath so it can be reused later. The old vertex array for filling has been renamed to fill_vbo.
2010-12-03 11:31:09 +00:00
Rename CoglVertexArray to CoglAttributeBuffer This is part of a broader cleanup of some of the experimental Cogl API. One of the reasons for this particular rename is to switch away from using the term "Array" which implies a regular, indexable layout which isn't the case. We also want to have a strongly implied relationship between CoglAttributes and CoglAttributeBuffers.
2011-03-02 15:01:41 +00:00
CoglAttributeBuffer *stroke_attribute_buffer;
CoglAttribute **stroke_attributes;
unsigned int stroke_n_attributes;
cogl-path: Optimise paths that are just a rectangle Drawing and clipping to paths is generally quite expensive because the geometry has to be tessellated into triangles in a single VBO which breaks up the journal batching. If we can detect when the path contains just a single rectangle then we can instead divert to calling cogl_rectangle which will take advantage of the journal, or by pushing a rectangle clip which usually ends up just using the scissor. This patch adds a boolean to each path to mark when it is a rectangle. It gets cleared whenever a node is added or gets set to TRUE whenever cogl2_path_rectangle is called. This doesn't try to catch cases where a rectangle is composed by cogl_path_line_to and cogl_path_move_to commands.
2011-03-09 17:46:23 +00:00
/* This is used as an optimisation for when the path contains a
single contour specified using cogl2_path_rectangle. Cogl is more
optimised to handle rectangles than paths so we can detect this
case and divert to the journal or a rectangle clip. If it is TRUE
then the entire path can be described by calling
_cogl_path_get_bounds */
cogl: Remove CoglBool, use gboolean instead This basically reverts commit 54735dec, which tried to avoid the GLib-defined types in favor the standard C ones. One exception to this is the bool type, for which the commit introduces a new type CoglBool. Let's just get rid of this type in favor of having consistency with the GLib types. Note by the way that neither CoglBool nor gboolean (which has a size of `int`) are completely compatible with bool (size `char`). https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
2018-11-24 12:04:47 +00:00
gboolean is_rectangle;
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 16:43:27 +00: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 23:35:47 +00:00
_cogl_add_path_to_stencil_buffer (CoglPath *path,
cogl: Remove CoglBool, use gboolean instead This basically reverts commit 54735dec, which tried to avoid the GLib-defined types in favor the standard C ones. One exception to this is the bool type, for which the commit introduces a new type CoglBool. Let's just get rid of this type in favor of having consistency with the GLib types. Note by the way that neither CoglBool nor gboolean (which has a size of `int`) are completely compatible with bool (size `char`). https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
2018-11-24 12:04:47 +00:00
gboolean merge,
gboolean need_clear);
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 16:43:27 +00:00
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 13:13:52 +00:00
void
_cogl_path_get_bounds (CoglPath *path,
float *min_x,
float *min_y,
float *max_x,
float *max_y);
cogl: Remove CoglBool, use gboolean instead This basically reverts commit 54735dec, which tried to avoid the GLib-defined types in favor the standard C ones. One exception to this is the bool type, for which the commit introduces a new type CoglBool. Let's just get rid of this type in favor of having consistency with the GLib types. Note by the way that neither CoglBool nor gboolean (which has a size of `int`) are completely compatible with bool (size `char`). https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
2018-11-24 12:04:47 +00:00
gboolean
cogl-path: Optimise paths that are just a rectangle Drawing and clipping to paths is generally quite expensive because the geometry has to be tessellated into triangles in a single VBO which breaks up the journal batching. If we can detect when the path contains just a single rectangle then we can instead divert to calling cogl_rectangle which will take advantage of the journal, or by pushing a rectangle clip which usually ends up just using the scissor. This patch adds a boolean to each path to mark when it is a rectangle. It gets cleared whenever a node is added or gets set to TRUE whenever cogl2_path_rectangle is called. This doesn't try to catch cases where a rectangle is composed by cogl_path_line_to and cogl_path_move_to commands.
2011-03-09 17:46:23 +00:00
_cogl_path_is_rectangle (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 16:43:27 +00:00
#endif /* __COGL_PATH_PRIVATE_H */
Copy permalink