isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-12-26 12:52:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
6bcee6e9f3
mutter/cogl/cogl-point-in-poly.c

102 lines
4.1 KiB
C
Raw Normal View History

cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
/*
* Point Inclusion in Polygon Test
*
* Copyright (c) 1970-2003, Wm. Randolph Franklin
* Copyright (C) 2011 Intel Corporation.
*
* 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:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimers.
* 2. Redistributions in binary form must reproduce the above
* copyright notice in the documentation and/or other materials
* provided with the distribution.
* 3. The name of W. Randolph Franklin may not be used to endorse or
* promote products derived from this Software without specific
* prior written permission.
*
* 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.
*
* Note:
* The algorithm for this point_in_poly() function was learnt from:
* http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html
*/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 23:19:30 +00:00
#include "cogl-util.h"
Add -Wmissing-declarations to maintainer flags and fix problems This option to GCC makes it give a warning whenever a global function is defined without a declaration. This should catch cases were we've defined a function but forgot to put it in a header. In that case it is either only used within one file so we should make it static or we should declare it in a header. The following changes where made to fix problems: • Some functions were made static • cogl-path.h (the one containing the 1.0 API) was split into two files, one defining the functions and one defining the enums so that cogl-path.c can include the enum and function declarations from the 2.0 API as well as the function declarations from the 1.0 API. • cogl2-clip-state has been removed. This only had one experimental function called cogl_clip_push_from_path but as this is unstable we might as well remove it favour of the equivalent cogl_framebuffer_* API. • The GLX, SDL and WGL winsys's now have a private header to define their get_vtable function instead of directly declaring in the C file where it is called. • All places that were calling COGL_OBJECT_DEFINE need to have the cogl_is_whatever function declared so these have been added either as a public function or in a private header. • Some files that were not including the header containing their function declarations have been fixed to do so. • Any unused error quark functions have been removed. If we later want them we should add them back one by one and add a declaration for them in a header. • _cogl_is_framebuffer has been renamed to cogl_is_framebuffer and made a public function with a declaration in cogl-framebuffer.h • Similarly for CoglOnscreen. • cogl_vdraw_indexed_attributes is called cogl_framebuffer_vdraw_indexed_attributes in the header. The definition has been changed to match the header. • cogl_index_buffer_allocate has been removed. This had no declaration and I'm not sure what it's supposed to do. • CoglJournal has been changed to use the internal CoglObject macro so that it won't define an exported cogl_is_journal symbol. • The _cogl_blah_pointer_from_handle functions have been removed. CoglHandle isn't used much anymore anyway and in the few places where it is used I think it's safe to just use the implicit cast from void* to the right type. • The test-utils.h header for the conformance tests explicitly disables the -Wmissing-declaration option using a pragma because all of the tests declare their main function without a header. Any mistakes relating to missing declarations aren't really important for the tests. • cogl_quaternion_init_from_quaternion and init_from_matrix have been given declarations in cogl-quaternion.h Reviewed-by: Robert Bragg <robert@linux.intel.com>
2012-03-06 18:21:28 +00:00
#include "cogl-point-in-poly-private.h"
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 23:19:30 +00:00
cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
#include <glib.h>
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 23:19:30 +00:00
/* We've made a notable change to the original algorithm referenced
* above to make sure we have reliable results for screen aligned
* rectangles even though there may be some numerical in-precision in
* how the vertices of the polygon were calculated.
*
* We've avoided introducing an epsilon factor to the comparisons
* since we feel there's a risk of changing some semantics in ways that
* might not be desirable. One of those is that if you transform two
* polygons which share an edge and test a point close to that edge
* then this algorithm will currently give a positive result for only
* one polygon.
*
* Another concern is the way this algorithm resolves the corner case
* where the horizontal ray being cast to count edge crossings may
* cross directly through a vertex. The solution is based on the "idea
* of Simulation of Simplicity" and "pretends to shift the ray
* infinitesimally down so that it either clearly intersects, or
* clearly doesn't touch". I'm not familiar with the idea myself so I
* expect a misplaced epsilon is likely to break that aspect of the
* algorithm.
*
* The simple solution we've gone for is to pixel align the polygon
* vertices which should eradicate most noise due to in-precision.
*/
cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
int
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 23:19:30 +00:00
_cogl_util_point_in_screen_poly (float point_x,
float point_y,
void *vertices,
size_t stride,
int n_vertices)
cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
{
int i, j, c = 0;
for (i = 0, j = n_vertices - 1; i < n_vertices; j = i++)
{
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 20:56:40 +00:00
float vert_xi = *(float *)((uint8_t *)vertices + i * stride);
float vert_xj = *(float *)((uint8_t *)vertices + j * stride);
float vert_yi = *(float *)((uint8_t *)vertices + i * stride +
cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
sizeof (float));
Switch use of primitive glib types to c99 equivalents The coding style has for a long time said to avoid using redundant glib data types such as gint or gchar etc because we feel that they make the code look unnecessarily foreign to developers coming from outside of the Gnome developer community. Note: When we tried to find the historical rationale for the types we just found that they were apparently only added for consistent syntax highlighting which didn't seem that compelling. Up until now we have been continuing to use some of the platform specific type such as gint{8,16,32,64} and gsize but this patch switches us over to using the standard c99 equivalents instead so we can further ensure that our code looks familiar to the widest range of C developers who might potentially contribute to Cogl. So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this switches all Cogl code to instead use the int{8,16,32,64}_t and uint{8,16,32,64}_t c99 types instead. Instead of gsize we now use size_t For now we are not going to use the c99 _Bool type and instead we have introduced a new CoglBool type to use instead of gboolean. Reviewed-by: Neil Roberts <neil@linux.intel.com> (cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
2012-04-16 20:56:40 +00:00
float vert_yj = *(float *)((uint8_t *)vertices + j * stride +
cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
sizeof (float));
util: tune point_in_poly test for polys in screen coords This makes a change to the original point_in_poly algorithm from: http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html The aim was to tune the test so that tests against screen aligned rectangles are more resilient to some in-precision in how we transformed that rectangle into screen coordinates. In particular gnome-shell was finding that for some stage sizes then row 0 of the stage would become a dead zone when going through the software picking fast-path and this was because the y position of screen aligned rectangles could end up as something like 0.00024 and the way the algorithm works it doesn't have any epsilon/fuz factor to consider that in-precision. We've avoided introducing an epsilon factor to the comparisons since we feel there's a risk of changing some semantics in ways that might not be desirable. One of those is that if you transform two polygons which share an edge and test a point close to that edge then this algorithm will currently give a positive result for only one polygon. Another concern is the way this algorithm resolves the corner case where the horizontal ray being cast to count edge crossings may cross directly through a vertex. The solution is based on the "idea of Simulation of Simplicity" and "pretends to shift the ray infinitesimally down so that it either clearly intersects, or clearly doesn't touch". I'm not familiar with the idea myself so I expect a misplaced epsilon is likely to break that aspect of the algorithm. The simple solution this patch applies is to pixel align the polygon vertices which should eradicate most noise due to in-precision. https://bugzilla.gnome.org/show_bug.cgi?id=641197
2011-03-03 23:19:30 +00:00
vert_xi = COGL_UTIL_NEARBYINT (vert_xi);
vert_xj = COGL_UTIL_NEARBYINT (vert_xj);
vert_yi = COGL_UTIL_NEARBYINT (vert_yi);
vert_yj = COGL_UTIL_NEARBYINT (vert_yj);
cogl: Adds _cogl_util_point_in_polygon API This adds a utility function that can determine if a given point intersects an arbitrary polygon, by counting how many edges a "semi-infinite" horizontal ray crosses from that point. The plan is to use this for a software based read-pixel fast path that avoids using the GPU to rasterize journaled primitives and can instead intersect a point being read with quads in the journal to determine the correct color.
2011-01-13 14:29:46 +00:00
if (((vert_yi > point_y) != (vert_yj > point_y)) &&
(point_x < (vert_xj - vert_xi) * (point_y - vert_yi) /
(vert_yj - vert_yi) + vert_xi) )
c = !c;
}
return c;
}
Reference in New Issue Copy Permalink