This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/blenkernel/intern/image_gen.c

351 lines
9.1 KiB
C
Raw Normal View History

2011-10-10 09:38:02 +00:00
/*
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program 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 General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* Contributor(s): Matt Ebb, Campbell Barton, Shuvro Sarker
*
* ***** END GPL LICENSE BLOCK *****
*/
2011-02-27 20:40:57 +00:00
/** \file blender/blenkernel/intern/image_gen.c
* \ingroup bke
*/
#include <math.h>
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
#include <stdlib.h>
#include "BKE_image.h"
#include "BLI_math_color.h"
#include "BLI_math_base.h"
#include "BLF_api.h"
void BKE_image_buf_fill_color(unsigned char *rect, float *rect_float, int width, int height, const float color[4])
{
int x, y;
/* blank image */
if (rect_float) {
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
for (x = 0; x < width; x++) {
copy_v4_v4(rect_float, color);
2012-05-06 17:22:54 +00:00
rect_float += 4;
}
}
}
if (rect) {
unsigned char ccol[4];
rgba_float_to_uchar(ccol, color);
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
for (x = 0; x < width; x++) {
2012-05-06 17:22:54 +00:00
rect[0] = ccol[0];
rect[1] = ccol[1];
rect[2] = ccol[2];
rect[3] = ccol[3];
rect += 4;
}
}
}
}
void BKE_image_buf_fill_checker(unsigned char *rect, float *rect_float, int width, int height)
{
/* these two passes could be combined into one, but it's more readable and
* easy to tweak like this, speed isn't really that much of an issue in this situation... */
2012-05-06 17:22:54 +00:00
int checkerwidth = 32, dark = 1;
int x, y;
2012-05-06 17:22:54 +00:00
unsigned char *rect_orig = rect;
float *rect_float_orig = rect_float;
float h = 0.0, hoffs = 0.0;
float hsv[3] = {0.0f, 0.9f, 0.9f};
float rgb[3];
/* checkers */
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
dark = powf(-1.0f, floorf(y / checkerwidth));
2012-05-06 17:22:54 +00:00
for (x = 0; x < width; x++) {
if (x % checkerwidth == 0) dark = -dark;
if (rect_float) {
if (dark > 0) {
2012-05-06 17:22:54 +00:00
rect_float[0] = rect_float[1] = rect_float[2] = 0.25f;
rect_float[3] = 1.0f;
}
else {
2012-05-06 17:22:54 +00:00
rect_float[0] = rect_float[1] = rect_float[2] = 0.58f;
rect_float[3] = 1.0f;
}
2012-05-06 17:22:54 +00:00
rect_float += 4;
}
else {
if (dark > 0) {
2012-05-06 17:22:54 +00:00
rect[0] = rect[1] = rect[2] = 64;
rect[3] = 255;
}
else {
2012-05-06 17:22:54 +00:00
rect[0] = rect[1] = rect[2] = 150;
rect[3] = 255;
}
2012-05-06 17:22:54 +00:00
rect += 4;
}
}
}
2012-05-06 17:22:54 +00:00
rect = rect_orig;
rect_float = rect_float_orig;
/* 2nd pass, colored + */
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
hoffs = 0.125f * floorf(y / checkerwidth);
2012-05-06 17:22:54 +00:00
for (x = 0; x < width; x++) {
h = 0.125f * floorf(x / checkerwidth);
if ((fabs((x % checkerwidth) - (checkerwidth / 2)) < 4) &&
(fabs((y % checkerwidth) - (checkerwidth / 2)) < 4))
{
if ((fabs((x % checkerwidth) - (checkerwidth / 2)) < 1) ||
(fabs((y % checkerwidth) - (checkerwidth / 2)) < 1))
{
hsv[0] = fmodf(fabs(h - hoffs), 1.0f);
hsv_to_rgb_v(hsv, rgb);
if (rect) {
rect[0] = (char)(rgb[0] * 255.0f);
rect[1] = (char)(rgb[1] * 255.0f);
rect[2] = (char)(rgb[2] * 255.0f);
2012-05-06 17:22:54 +00:00
rect[3] = 255;
}
if (rect_float) {
rect_float[0] = rgb[0];
rect_float[1] = rgb[1];
rect_float[2] = rgb[2];
2012-05-06 17:22:54 +00:00
rect_float[3] = 1.0f;
}
}
}
2012-05-06 17:22:54 +00:00
if (rect_float) rect_float += 4;
if (rect) rect += 4;
}
}
}
/* Utility functions for BKE_image_buf_fill_checker_color */
2012-05-06 17:22:54 +00:00
#define BLEND_FLOAT(real, add) (real + add <= 1.0f) ? (real + add) : 1.0f
#define BLEND_CHAR(real, add) ((real + (char)(add * 255.0f)) <= 255) ? (real + (char)(add * 255.0f)) : 255
static void checker_board_color_fill(unsigned char *rect, float *rect_float, int width, int height)
{
int hue_step, y, x;
float hsv[3], rgb[3];
hsv[1] = 1.0;
2012-05-06 17:22:54 +00:00
hue_step = power_of_2_max_i(width / 8);
if (hue_step < 8) hue_step = 8;
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
hsv[2] = 0.1 + (y * (0.4 / height)); /* use a number lower then 1.0 else its too bright */
2012-05-06 17:22:54 +00:00
for (x = 0; x < width; x++) {
hsv[0] = (float)((double)(x / hue_step) * 1.0 / width * hue_step);
hsv_to_rgb_v(hsv, rgb);
if (rect) {
rect[0] = (char)(rgb[0] * 255.0f);
rect[1] = (char)(rgb[1] * 255.0f);
rect[2] = (char)(rgb[2] * 255.0f);
2012-05-06 17:22:54 +00:00
rect[3] = 255;
rect += 4;
}
if (rect_float) {
rect_float[0] = rgb[0];
rect_float[1] = rgb[1];
rect_float[2] = rgb[2];
2012-05-06 17:22:54 +00:00
rect_float[3] = 1.0f;
rect_float += 4;
}
}
}
}
static void checker_board_color_tint(unsigned char *rect, float *rect_float, int width, int height, int size, float blend)
{
int x, y;
2012-05-06 17:22:54 +00:00
float blend_half = blend * 0.5f;
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
for (x = 0; x < width; x++) {
if (((y / size) % 2 == 1 && (x / size) % 2 == 1) || ( (y / size) % 2 == 0 && (x / size) % 2 == 0)) {
if (rect) {
2012-05-06 17:22:54 +00:00
rect[0] = (char)BLEND_CHAR(rect[0], blend);
rect[1] = (char)BLEND_CHAR(rect[1], blend);
rect[2] = (char)BLEND_CHAR(rect[2], blend);
rect[3] = 255;
rect += 4;
}
if (rect_float) {
2012-05-06 17:22:54 +00:00
rect_float[0] = BLEND_FLOAT(rect_float[0], blend);
rect_float[1] = BLEND_FLOAT(rect_float[1], blend);
rect_float[2] = BLEND_FLOAT(rect_float[2], blend);
rect_float[3] = 1.0f;
rect_float += 4;
}
}
else {
if (rect) {
2012-05-06 17:22:54 +00:00
rect[0] = (char)BLEND_CHAR(rect[0], blend_half);
rect[1] = (char)BLEND_CHAR(rect[1], blend_half);
rect[2] = (char)BLEND_CHAR(rect[2], blend_half);
rect[3] = 255;
rect += 4;
}
if (rect_float) {
2012-05-06 17:22:54 +00:00
rect_float[0] = BLEND_FLOAT(rect_float[0], blend_half);
rect_float[1] = BLEND_FLOAT(rect_float[1], blend_half);
rect_float[2] = BLEND_FLOAT(rect_float[2], blend_half);
rect_float[3] = 1.0f;
rect_float += 4;
}
}
}
}
}
static void checker_board_grid_fill(unsigned char *rect, float *rect_float, int width, int height, float blend)
{
int x, y;
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y++) {
for (x = 0; x < width; x++) {
if (((y % 32) == 0) || ((x % 32) == 0) || x == 0) {
if (rect) {
2012-05-06 17:22:54 +00:00
rect[0] = BLEND_CHAR(rect[0], blend);
rect[1] = BLEND_CHAR(rect[1], blend);
rect[2] = BLEND_CHAR(rect[2], blend);
rect[3] = 255;
rect += 4;
}
if (rect_float) {
2012-05-06 17:22:54 +00:00
rect_float[0] = BLEND_FLOAT(rect_float[0], blend);
rect_float[1] = BLEND_FLOAT(rect_float[1], blend);
rect_float[2] = BLEND_FLOAT(rect_float[2], blend);
rect_float[3] = 1.0f;
rect_float += 4;
}
}
else {
if (rect_float) rect_float += 4;
if (rect) rect += 4;
}
}
}
}
/* defined in image.c */
static void checker_board_text(unsigned char *rect, float *rect_float, int width, int height, int step, int outline)
{
int x, y;
int pen_x, pen_y;
2012-05-06 17:22:54 +00:00
char text[3] = {'A', '1', '\0'};
const int mono = blf_mono_font;
BLF_size(mono, 54, 72); /* hard coded size! */
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
/* OCIO_TODO: using NULL as display will assume using sRGB display
* this is correct since currently generated images are assumed to be in sRGB space,
* but this would probably needed to be fixed in some way
*/
BLF_buffer(mono, rect_float, rect, width, height, 4, NULL);
2012-05-06 17:22:54 +00:00
for (y = 0; y < height; y += step) {
text[1] = '1';
2012-05-06 17:22:54 +00:00
for (x = 0; x < width; x += step) {
/* hard coded offset */
pen_x = x + 33;
pen_y = y + 44;
/* terribly crappy outline font! */
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_buffer_col(mono, 1.0, 1.0, 1.0, 1.0);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x - outline, pen_y, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x + outline, pen_y, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x, pen_y - outline, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x, pen_y + outline, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x - outline, pen_y - outline, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x + outline, pen_y + outline, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x - outline, pen_y + outline, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
2012-05-06 17:22:54 +00:00
BLF_position(mono, pen_x + outline, pen_y - outline, 0.0);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
BLF_draw_buffer(mono, text);
BLF_buffer_col(mono, 0.0, 0.0, 0.0, 1.0);
BLF_position(mono, pen_x, pen_y, 0.0);
BLF_draw_buffer(mono, text);
text[1]++;
}
text[0]++;
}
/* cleanup the buffer. */
BLF_buffer(mono, NULL, NULL, 0, 0, 0, FALSE);
}
void BKE_image_buf_fill_checker_color(unsigned char *rect, float *rect_float, int width, int height)
{
checker_board_color_fill(rect, rect_float, width, height);
checker_board_color_tint(rect, rect_float, width, height, 1, 0.03f);
checker_board_color_tint(rect, rect_float, width, height, 4, 0.05f);
checker_board_color_tint(rect, rect_float, width, height, 32, 0.07f);
checker_board_color_tint(rect, rect_float, width, height, 128, 0.15f);
2012-05-06 17:22:54 +00:00
checker_board_grid_fill(rect, rect_float, width, height, 1.0f / 4.0f);
checker_board_text(rect, rect_float, width, height, 128, 2);
}