brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
806a2e5813
mutter/cogl/cogl-point-in-poly-private.h

41 lines
1.2 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 09:29:46 -05:00
/*
* Cogl
*
* An object oriented GL/GLES Abstraction/Utility Layer
*
* Copyright (C) 2011 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_POINT_INT_POLYGON_PRIVATE_H
#define __COGL_POINT_INT_POLYGON_PRIVATE_H
#include <glib.h>
Fixes for --disable-glib This fixes some problems which were stopping --disable-glib from working properly: • A lot of the public headers were including glib.h. This shouldn't be necessary because the API doesn't expose any glib types. Otherwise any apps would require glib in order to get the header. • The public headers were using G_BEGIN_DECLS. There is now a replacement macro called COGL_BEGIN_DECLS which is defined in cogl-types.h. • A similar fix has been done for G_GNUC_NULL_TERMINATED and G_GNUC_DEPRECATED. • The CFLAGS were not including $(builddir)/deps/glib which was preventing it finding the generated glibconfig.h when building out of tree. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 4138b3141c2f39cddaea3d72bfc04342ed5092d0)
2012-11-22 13:01:10 -05:00
COGL_BEGIN_DECLS
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 09:29:46 -05: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 18:19:30 -05: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 09:29:46 -05:00
Fixes for --disable-glib This fixes some problems which were stopping --disable-glib from working properly: • A lot of the public headers were including glib.h. This shouldn't be necessary because the API doesn't expose any glib types. Otherwise any apps would require glib in order to get the header. • The public headers were using G_BEGIN_DECLS. There is now a replacement macro called COGL_BEGIN_DECLS which is defined in cogl-types.h. • A similar fix has been done for G_GNUC_NULL_TERMINATED and G_GNUC_DEPRECATED. • The CFLAGS were not including $(builddir)/deps/glib which was preventing it finding the generated glibconfig.h when building out of tree. Reviewed-by: Robert Bragg <robert@linux.intel.com> (cherry picked from commit 4138b3141c2f39cddaea3d72bfc04342ed5092d0)
2012-11-22 13:01:10 -05:00
COGL_END_DECLS
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 09:29:46 -05:00
#endif /* __COGL_POINT_INT_POLYGON_PRIVATE_H */
Reference in New Issue Copy Permalink