diff options
Diffstat (limited to 'source/blender/blenlib/intern')
| -rw-r--r-- | source/blender/blenlib/intern/fileops.c | 2 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/freetypefont.c | 174 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/math_color_inline.c | 12 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/math_geom.c | 4 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/math_vector.c | 13 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/path_util.c | 4 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/scanfill.c | 2 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/storage.c | 2 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/threads.c | 2 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/time.c | 2 | ||||
| -rw-r--r-- | source/blender/blenlib/intern/voronoi.c | 15 |
11 files changed, 126 insertions, 106 deletions
diff --git a/source/blender/blenlib/intern/fileops.c b/source/blender/blenlib/intern/fileops.c index ec7b59702bd..5f564f71646 100644 --- a/source/blender/blenlib/intern/fileops.c +++ b/source/blender/blenlib/intern/fileops.c @@ -401,7 +401,7 @@ static void join_dirfile_alloc(char **dst, size_t *alloc_len, const char *dir, c { size_t len = strlen(dir) + strlen(file) + 1; - if (!*dst) + if (*dst == NULL) *dst = MEM_callocN(len + 1, "join_dirfile_alloc path"); else if (*alloc_len < len) *dst = MEM_reallocN(*dst, len + 1); diff --git a/source/blender/blenlib/intern/freetypefont.c b/source/blender/blenlib/intern/freetypefont.c index a0e72af8131..eb2070bce76 100644 --- a/source/blender/blenlib/intern/freetypefont.c +++ b/source/blender/blenlib/intern/freetypefont.c @@ -545,90 +545,90 @@ typedef struct FT_Outline_ #endif -/***//* -from: http://www.freetype.org/freetype2/docs/glyphs/glyphs-6.html#section-1 - -Vectorial representation of Freetype glyphs - -The source format of outlines is a collection of closed paths called "contours". Each contour is -made of a series of line segments and bezier arcs. Depending on the file format, these can be -second-order or third-order polynomials. The former are also called quadratic or conic arcs, and -they come from the TrueType format. The latter are called cubic arcs and mostly come from the -Type1 format. - -Each arc is described through a series of start, end and control points. Each point of the outline -has a specific tag which indicates wether it is used to describe a line segment or an arc. - - -The following rules are applied to decompose the contour's points into segments and arcs : - -# two successive "on" points indicate a line segment joining them. - -# one conic "off" point amidst two "on" points indicates a conic bezier arc, the "off" point being - the control point, and the "on" ones the start and end points. - -# Two successive cubic "off" points amidst two "on" points indicate a cubic bezier arc. There must - be exactly two cubic control points and two on points for each cubic arc (using a single cubic - "off" point between two "on" points is forbidden, for example). - -# finally, two successive conic "off" points forces the rasterizer to create (during the scan-line - conversion process exclusively) a virtual "on" point amidst them, at their exact middle. This - greatly facilitates the definition of successive conic bezier arcs. Moreover, it's the way - outlines are described in the TrueType specification. - -Note that it is possible to mix conic and cubic arcs in a single contour, even though no current -font driver produces such outlines. - - * # on - * off - __---__ - #-__ _-- -_ - --__ _- - - --__ # \ - --__ # - -# - Two "on" points - Two "on" points and one "conic" point - between them - - - - * - # __ Two "on" points with two "conic" - \ - - points between them. The point - \ / \ marked '0' is the middle of the - - 0 \ "off" points, and is a 'virtual' - -_ _- # "on" point where the curve passes. - -- It does not appear in the point - list. - * - - - - - * # on - * * off - __---__ - _-- -_ - _- - - # \ - # - - Two "on" points - and two "cubic" point - between them - - -Each glyph's original outline points are located on a grid of indivisible units. The points are stored -in the font file as 16-bit integer grid coordinates, with the grid origin's being at (0, 0); they thus -range from -16384 to 16383. - -Convert conic to bezier arcs: -Conic P0 P1 P2 -Bezier B0 B1 B2 B3 -B0=P0 -B1=(P0+2*P1)/3 -B2=(P2+2*P1)/3 -B3=P2 - -*//****/ +/* + * from: http://www.freetype.org/freetype2/docs/glyphs/glyphs-6.html#section-1 + * + * Vectorial representation of Freetype glyphs + * + * The source format of outlines is a collection of closed paths called "contours". Each contour is + * made of a series of line segments and bezier arcs. Depending on the file format, these can be + * second-order or third-order polynomials. The former are also called quadratic or conic arcs, and + * they come from the TrueType format. The latter are called cubic arcs and mostly come from the + * Type1 format. + * + * Each arc is described through a series of start, end and control points. Each point of the outline + * has a specific tag which indicates wether it is used to describe a line segment or an arc. + * + * + * The following rules are applied to decompose the contour's points into segments and arcs : + * + * # two successive "on" points indicate a line segment joining them. + * + * # one conic "off" point amidst two "on" points indicates a conic bezier arc, the "off" point being + * the control point, and the "on" ones the start and end points. + * + * # Two successive cubic "off" points amidst two "on" points indicate a cubic bezier arc. There must + * be exactly two cubic control points and two on points for each cubic arc (using a single cubic + * "off" point between two "on" points is forbidden, for example). + * + * # finally, two successive conic "off" points forces the rasterizer to create (during the scan-line + * conversion process exclusively) a virtual "on" point amidst them, at their exact middle. This + * greatly facilitates the definition of successive conic bezier arcs. Moreover, it's the way + * outlines are described in the TrueType specification. + * + * Note that it is possible to mix conic and cubic arcs in a single contour, even though no current + * font driver produces such outlines. + * + * * # on + * * off + * __---__ + * #-__ _-- -_ + * --__ _- - + * --__ # \ + * --__ # + * -# + * Two "on" points + * Two "on" points and one "conic" point + * between them + * + * + * + * * + * # __ Two "on" points with two "conic" + * \ - - points between them. The point + * \ / \ marked '0' is the middle of the + * - 0 \ "off" points, and is a 'virtual' + * -_ _- # "on" point where the curve passes. + * -- It does not appear in the point + * list. + * * + * + * + * + * + * * # on + * * * off + * __---__ + * _-- -_ + * _- - + * # \ + * # + * + * Two "on" points + * and two "cubic" point + * between them + * + * + * Each glyph's original outline points are located on a grid of indivisible units. The points are stored + * in the font file as 16-bit integer grid coordinates, with the grid origin's being at (0, 0); they thus + * range from -16384 to 16383. + * + * Convert conic to bezier arcs: + * Conic P0 P1 P2 + * Bezier B0 B1 B2 B3 + * B0=P0 + * B1=(P0+2*P1)/3 + * B2=(P2+2*P1)/3 + * B3=P2 + * + */ diff --git a/source/blender/blenlib/intern/math_color_inline.c b/source/blender/blenlib/intern/math_color_inline.c index 23d70bd148b..58ee898ea28 100644 --- a/source/blender/blenlib/intern/math_color_inline.c +++ b/source/blender/blenlib/intern/math_color_inline.c @@ -222,8 +222,16 @@ MINLINE void cpack_cpy_3ub(unsigned char r_col[3], const unsigned int pack) r_col[2] = ((pack) >> 16) & 0xFF; } -/* XXX - investigate when/why rgb_to_bw & rgb_to_grayscale are different, - * and why we use both! whats the purpose of this? */ +/* TODO: + * + * regarding #rgb_to_bw vs #rgb_to_grayscale, + * it seems nobody knows why we have both functions which convert color to greys + * but with different influences, this is quite stupid, and should be resolved + * by someone who knows this stuff: see this thread + * http://lists.blender.org/pipermail/bf-committers/2012-June/037180.html + * + * Only conclusion is that rgb_to_grayscale is used more for compositing. + */ MINLINE float rgb_to_bw(const float rgb[3]) { return 0.35f * rgb[0] + 0.45f * rgb[1] + 0.2f * rgb[2]; diff --git a/source/blender/blenlib/intern/math_geom.c b/source/blender/blenlib/intern/math_geom.c index d35624e84d2..e51d0d2645f 100644 --- a/source/blender/blenlib/intern/math_geom.c +++ b/source/blender/blenlib/intern/math_geom.c @@ -901,8 +901,8 @@ static int getLowestRoot(const float a, const float b, const float c, const floa // If determinant is negative it means no solutions. if (determinant >= 0.0f) { - // calculate the two roots: (if determinant == 0 then - // x1==x2 but lets disregard that slight optimization) + /* calculate the two roots: (if determinant == 0 then + * x1==x2 but lets disregard that slight optimization) */ float sqrtD = (float)sqrt(determinant); float r1 = (-b - sqrtD) / (2.0f * a); float r2 = (-b + sqrtD) / (2.0f * a); diff --git a/source/blender/blenlib/intern/math_vector.c b/source/blender/blenlib/intern/math_vector.c index d939576904e..5cda1c0b81f 100644 --- a/source/blender/blenlib/intern/math_vector.c +++ b/source/blender/blenlib/intern/math_vector.c @@ -136,6 +136,19 @@ float angle_v3v3v3(const float v1[3], const float v2[3], const float v3[3]) return angle_normalized_v3v3(vec1, vec2); } +/* Quicker than full angle computation */ +float cos_v3v3v3(const float p1[3], const float p2[3], const float p3[3]) +{ + float vec1[3], vec2[3]; + + sub_v3_v3v3(vec1, p2, p1); + sub_v3_v3v3(vec2, p2, p3); + normalize_v3(vec1); + normalize_v3(vec2); + + return dot_v3v3(vec1, vec2); +} + /* Return the shortest angle in radians between the 2 vectors */ float angle_v3v3(const float v1[3], const float v2[3]) { diff --git a/source/blender/blenlib/intern/path_util.c b/source/blender/blenlib/intern/path_util.c index 46a0ac630c1..c85efc1fd9a 100644 --- a/source/blender/blenlib/intern/path_util.c +++ b/source/blender/blenlib/intern/path_util.c @@ -806,7 +806,7 @@ void BLI_getlastdir(const char *dir, char *last, const size_t maxlen) const char *BLI_getDefaultDocumentFolder(void) { #ifndef WIN32 - const char *xdg_documents_dir= getenv("XDG_DOCUMENTS_DIR"); + const char *xdg_documents_dir = getenv("XDG_DOCUMENTS_DIR"); if (xdg_documents_dir) return xdg_documents_dir; @@ -1643,7 +1643,7 @@ int BLI_rebase_path(char *abs, size_t abs_len, char *rel, size_t rel_len, const strncat(rel, base, rel_len); } - /* return 2 if src=dest */ + /* return 2 if (src == dest) */ if (BLI_path_cmp(path, dest_path) == 0) { // if (G.debug & G_DEBUG) printf("%s and %s are the same file\n", path, dest_path); return BLI_REBASE_IDENTITY; diff --git a/source/blender/blenlib/intern/scanfill.c b/source/blender/blenlib/intern/scanfill.c index 94752965f3a..1f0bd445831 100644 --- a/source/blender/blenlib/intern/scanfill.c +++ b/source/blender/blenlib/intern/scanfill.c @@ -288,7 +288,7 @@ static void mergepolysSimp(ScanFillContext *sf_ctx, PolyFill *pf1, PolyFill *pf2 } static short testedgeside(const float v1[2], const float v2[2], const float v3[2]) -/* is v3 to the right of v1-v2 ? With exception: v3==v1 || v3==v2 */ +/* is v3 to the right of v1-v2 ? With exception: v3 == v1 || v3 == v2 */ { float inp; diff --git a/source/blender/blenlib/intern/storage.c b/source/blender/blenlib/intern/storage.c index d4f251d4f5e..965e8b5eec3 100644 --- a/source/blender/blenlib/intern/storage.c +++ b/source/blender/blenlib/intern/storage.c @@ -102,7 +102,7 @@ static struct ListBase dirbase_ = {NULL, NULL}; static struct ListBase *dirbase = &dirbase_; /* can return NULL when the size is not big enough */ -char *BLI_current_working_dir(char *dir, const int maxncpy) +char *BLI_current_working_dir(char *dir, const size_t maxncpy) { const char *pwd = getenv("PWD"); if (pwd) { diff --git a/source/blender/blenlib/intern/threads.c b/source/blender/blenlib/intern/threads.c index d591f98ddc0..348fa29eae7 100644 --- a/source/blender/blenlib/intern/threads.c +++ b/source/blender/blenlib/intern/threads.c @@ -96,7 +96,7 @@ static void *thread_tls_data; * } * // conditions to exit loop * if (if escape loop event) { - * if (BLI_available_threadslots(&lb)==maxthreads) + * if (BLI_available_threadslots(&lb) == maxthreads) * break; * } * } diff --git a/source/blender/blenlib/intern/time.c b/source/blender/blenlib/intern/time.c index 64f007513ed..bf9720fee09 100644 --- a/source/blender/blenlib/intern/time.c +++ b/source/blender/blenlib/intern/time.c @@ -37,7 +37,7 @@ double PIL_check_seconds_timer(void) { - static int hasperfcounter = -1; /* -1==unknown */ + static int hasperfcounter = -1; /* (-1 == unknown) */ static double perffreq; if (hasperfcounter == -1) { diff --git a/source/blender/blenlib/intern/voronoi.c b/source/blender/blenlib/intern/voronoi.c index 727e42dc8de..eeb0187b74c 100644 --- a/source/blender/blenlib/intern/voronoi.c +++ b/source/blender/blenlib/intern/voronoi.c @@ -28,7 +28,7 @@ * http://blog.ivank.net/fortunes-algorithm-and-implementation.html */ -/** \file blender/blenkernel/intern/tracking.c +/** \file blender/blenkernel/intern/voronoi.c * \ingroup bli */ @@ -790,16 +790,15 @@ void BLI_voronoi_triangulate(const VoronoiSite *sites, int sites_total, ListBase int ok_start = TRUE, ok_end = TRUE; while (test_edge) { - float v1[2], v2[2]; - - sub_v2_v2v2(v1, edge->start, sites[i].co); - sub_v2_v2v2(v2, edge->end, sites[i].co); - - if (ok_start && !testVoronoiEdge(sites[i].co, edge->start, test_edge)) + if (ok_start && !testVoronoiEdge(sites[i].co, edge->start, test_edge)) { ok_start = FALSE; + break; + } - if (ok_end && !testVoronoiEdge(sites[i].co, edge->end, test_edge)) + if (ok_end && !testVoronoiEdge(sites[i].co, edge->end, test_edge)) { ok_end = FALSE; + break; + } test_edge = test_edge->next; } |