2009-04-09 18:11:18 +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,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2009-04-09 18:11:18 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2009 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Contributor(s): Blender Foundation
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <limits.h>
|
|
|
|
#include <math.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
#include "DNA_screen_types.h"
|
|
|
|
#include "DNA_userdef_types.h"
|
|
|
|
|
2009-11-10 20:43:45 +00:00
|
|
|
#include "BLI_math.h"
|
2009-04-09 18:11:18 +00:00
|
|
|
#include "BLI_listbase.h"
|
|
|
|
#include "BLI_rect.h"
|
|
|
|
#include "BLI_string.h"
|
|
|
|
|
|
|
|
#include "BKE_global.h"
|
|
|
|
|
|
|
|
|
|
|
|
#include "BLF_api.h"
|
|
|
|
|
|
|
|
#include "UI_interface.h"
|
|
|
|
|
|
|
|
#include "ED_datafiles.h"
|
|
|
|
|
|
|
|
#include "interface_intern.h"
|
|
|
|
|
|
|
|
|
|
|
|
/* style + theme + layout-engine = UI */
|
|
|
|
|
|
|
|
/*
|
|
|
|
This is a complete set of layout rules, the 'state' of the Layout
|
|
|
|
Engine. Multiple styles are possible, defined via C or Python. Styles
|
|
|
|
get a name, and will typically get activated per region type, like
|
|
|
|
"Header", or "Listview" or "Toolbar". Properties of Style definitions
|
|
|
|
are:
|
|
|
|
|
|
|
|
- default collumn properties, internal spacing, aligning, min/max width
|
|
|
|
- button alignment rules (for groups)
|
|
|
|
- label placement rules
|
|
|
|
- internal labeling or external labeling default
|
|
|
|
- default minimum widths for buttons/labels (in amount of characters)
|
|
|
|
- font types, styles and relative sizes for Panel titles, labels, etc.
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
/* ********************************************** */
|
|
|
|
|
|
|
|
static uiStyle *ui_style_new(ListBase *styles, const char *name)
|
|
|
|
{
|
|
|
|
uiStyle *style= MEM_callocN(sizeof(uiStyle), "new style");
|
|
|
|
|
|
|
|
BLI_addtail(styles, style);
|
|
|
|
BLI_strncpy(style->name, name, MAX_STYLE_NAME);
|
|
|
|
|
2009-07-10 20:43:32 +00:00
|
|
|
style->panelzoom= 1.0;
|
|
|
|
|
2009-04-09 18:11:18 +00:00
|
|
|
style->paneltitle.uifont_id= UIFONT_DEFAULT;
|
2009-07-15 22:58:12 +00:00
|
|
|
style->paneltitle.points= 12;
|
2009-07-21 01:26:17 +00:00
|
|
|
style->paneltitle.kerning= 1;
|
2009-08-03 10:54:02 +00:00
|
|
|
style->paneltitle.shadow= 1;
|
|
|
|
style->paneltitle.shadx= 0;
|
|
|
|
style->paneltitle.shady= -1;
|
|
|
|
style->paneltitle.shadowalpha= 0.15f;
|
|
|
|
style->paneltitle.shadowcolor= 1.0f;
|
2009-04-09 18:11:18 +00:00
|
|
|
|
|
|
|
style->grouplabel.uifont_id= UIFONT_DEFAULT;
|
|
|
|
style->grouplabel.points= 12;
|
2009-07-21 01:26:17 +00:00
|
|
|
style->grouplabel.kerning= 1;
|
2009-04-10 14:06:24 +00:00
|
|
|
style->grouplabel.shadow= 3;
|
2009-08-03 10:54:02 +00:00
|
|
|
style->grouplabel.shadx= 0;
|
2009-04-10 14:06:24 +00:00
|
|
|
style->grouplabel.shady= -1;
|
2009-04-09 18:11:18 +00:00
|
|
|
style->grouplabel.shadowalpha= 0.25f;
|
|
|
|
|
|
|
|
style->widgetlabel.uifont_id= UIFONT_DEFAULT;
|
|
|
|
style->widgetlabel.points= 11;
|
2009-07-21 01:26:17 +00:00
|
|
|
style->widgetlabel.kerning= 1;
|
2009-04-10 14:06:24 +00:00
|
|
|
style->widgetlabel.shadow= 3;
|
2009-08-03 10:54:02 +00:00
|
|
|
style->widgetlabel.shadx= 0;
|
2009-04-10 14:06:24 +00:00
|
|
|
style->widgetlabel.shady= -1;
|
2009-08-03 10:54:02 +00:00
|
|
|
style->widgetlabel.shadowalpha= 0.15f;
|
2009-04-10 14:06:24 +00:00
|
|
|
style->widgetlabel.shadowcolor= 1.0f;
|
2009-04-09 18:11:18 +00:00
|
|
|
|
|
|
|
style->widget.uifont_id= UIFONT_DEFAULT;
|
|
|
|
style->widget.points= 11;
|
2009-07-21 01:26:17 +00:00
|
|
|
style->widget.kerning= 1;
|
2009-04-09 18:11:18 +00:00
|
|
|
style->widget.shadowalpha= 0.25f;
|
2009-04-27 18:05:58 +00:00
|
|
|
|
2009-07-23 20:50:24 +00:00
|
|
|
style->columnspace= 8;
|
2009-04-27 18:05:58 +00:00
|
|
|
style->templatespace= 5;
|
|
|
|
style->boxspace= 5;
|
2009-07-23 20:50:24 +00:00
|
|
|
style->buttonspacex= 8;
|
2009-04-27 18:05:58 +00:00
|
|
|
style->buttonspacey= 2;
|
UI: Layout Engine
* Buttons are now created first, and after that the layout is computed.
This means the layout engine now works at button level, and makes it
easier to write templates. Otherwise you had to store all info and
create the buttons later.
* Added interface_templates.c as a separate file to put templates in.
These can contain regular buttons, and can be put in a Free layout,
which means you can specify manual coordinates, but still get nested
correct inside other layouts.
* API was changed to allow better nesting. Previously items were added
in the last added layout specifier, i.e. one level up in the layout
hierarchy. This doesn't work well in always, so now when creating things
like rows or columns it always returns a layout which you have to add
the items in. All py scripts were updated to follow this.
* Computing the layout now goes in two passes, first estimating the
required width/height of all nested layouts, and then in the second
pass using the results of that to decide on the actual locations.
* Enum and array buttons now follow the direction of the layout, i.e.
they are vertical or horizontal depending if they are in a column or row.
* Color properties now get a color picker, and only get the additional
RGB sliders with Expand=True.
* File/directory string properties now get a button next to them for
opening the file browse, though this is not implemented yet.
* Layout items can now be aligned, set align=True when creating a column,
row, etc.
* Buttons now get a minimum width of one icon (avoids squashing icon
buttons).
* Moved some more space variables into Style.
2009-05-15 11:19:59 +00:00
|
|
|
style->panelspace= 8;
|
|
|
|
style->panelouter= 4;
|
2009-04-09 18:11:18 +00:00
|
|
|
|
|
|
|
return style;
|
|
|
|
}
|
|
|
|
|
|
|
|
static uiFont *uifont_to_blfont(int id)
|
|
|
|
{
|
|
|
|
uiFont *font= U.uifonts.first;
|
|
|
|
|
|
|
|
for(; font; font= font->next) {
|
|
|
|
if(font->uifont_id==id) {
|
|
|
|
return font;
|
|
|
|
}
|
|
|
|
}
|
2009-04-15 14:43:54 +00:00
|
|
|
return U.uifonts.first;
|
2009-04-09 18:11:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* *************** draw ************************ */
|
|
|
|
|
2009-04-10 14:06:24 +00:00
|
|
|
void uiStyleFontDraw(uiFontStyle *fs, rcti *rect, char *str)
|
2009-04-09 18:11:18 +00:00
|
|
|
{
|
|
|
|
float height;
|
|
|
|
int xofs=0, yofs;
|
|
|
|
|
2009-04-10 14:06:24 +00:00
|
|
|
uiStyleFontSet(fs);
|
2009-04-09 18:11:18 +00:00
|
|
|
|
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
|
|
|
height= BLF_height(fs->uifont_id, "2"); /* correct offset is on baseline, the j is below that */
|
2009-04-09 18:11:18 +00:00
|
|
|
yofs= floor( 0.5f*(rect->ymax - rect->ymin - height));
|
|
|
|
|
|
|
|
if(fs->align==UI_STYLE_TEXT_CENTER)
|
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
|
|
|
xofs= floor( 0.5f*(rect->xmax - rect->xmin - BLF_width(fs->uifont_id, str)));
|
2009-04-10 14:06:24 +00:00
|
|
|
else if(fs->align==UI_STYLE_TEXT_RIGHT)
|
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
|
|
|
xofs= rect->xmax - rect->xmin - BLF_width(fs->uifont_id, str) - 1;
|
2009-04-09 18:11:18 +00:00
|
|
|
|
2009-04-10 14:06:24 +00:00
|
|
|
/* clip is very strict, so we give it some space */
|
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_clipping(fs->uifont_id, rect->xmin-1, rect->ymin-4, rect->xmax+1, rect->ymax+4);
|
|
|
|
BLF_enable(fs->uifont_id, BLF_CLIPPING);
|
|
|
|
BLF_position(fs->uifont_id, rect->xmin+xofs, rect->ymin+yofs, 0.0f);
|
2009-04-10 14:06:24 +00:00
|
|
|
|
2009-06-23 16:27:35 +00:00
|
|
|
if (fs->shadow) {
|
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_enable(fs->uifont_id, BLF_SHADOW);
|
|
|
|
BLF_shadow(fs->uifont_id, fs->shadow, fs->shadowcolor, fs->shadowcolor, fs->shadowcolor, fs->shadowalpha);
|
|
|
|
BLF_shadow_offset(fs->uifont_id, fs->shadx, fs->shady);
|
2009-06-23 16:27:35 +00:00
|
|
|
}
|
|
|
|
|
2009-07-10 22:16:25 +00:00
|
|
|
if (fs->kerning == 1)
|
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_enable(fs->uifont_id, BLF_KERNING_DEFAULT);
|
2009-07-10 22:16:25 +00:00
|
|
|
|
2010-11-11 06:35:45 +00:00
|
|
|
BLF_draw(fs->uifont_id, str, 65535); /* XXX, use real length */
|
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_disable(fs->uifont_id, BLF_CLIPPING);
|
2009-06-23 16:27:35 +00:00
|
|
|
if (fs->shadow)
|
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_disable(fs->uifont_id, BLF_SHADOW);
|
2009-07-10 22:16:25 +00:00
|
|
|
if (fs->kerning == 1)
|
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_disable(fs->uifont_id, BLF_KERNING_DEFAULT);
|
2009-04-09 18:11:18 +00:00
|
|
|
}
|
|
|
|
|
2009-10-19 03:54:30 +00:00
|
|
|
/* drawn same as above, but at 90 degree angle */
|
|
|
|
void uiStyleFontDrawRotated(uiFontStyle *fs, rcti *rect, char *str)
|
|
|
|
{
|
|
|
|
float height;
|
|
|
|
int xofs, yofs;
|
|
|
|
float angle;
|
|
|
|
rcti txtrect;
|
|
|
|
|
|
|
|
uiStyleFontSet(fs);
|
|
|
|
|
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
|
|
|
height= BLF_height(fs->uifont_id, "2"); /* correct offset is on baseline, the j is below that */
|
2009-10-19 03:54:30 +00:00
|
|
|
/* becomes x-offset when rotated */
|
|
|
|
xofs= floor( 0.5f*(rect->ymax - rect->ymin - height)) + 1;
|
|
|
|
|
|
|
|
/* ignore UI_STYLE, always aligned to top */
|
|
|
|
|
|
|
|
/* rotate counter-clockwise for now (assumes left-to-right language)*/
|
|
|
|
xofs+= height;
|
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
|
|
|
yofs= BLF_width(fs->uifont_id, str) + 5;
|
2009-10-19 03:54:30 +00:00
|
|
|
angle= 90.0f;
|
|
|
|
|
|
|
|
/* translate rect to vertical */
|
|
|
|
txtrect.xmin= rect->xmin - (rect->ymax - rect->ymin);
|
|
|
|
txtrect.ymin= rect->ymin - (rect->xmax - rect->xmin);
|
|
|
|
txtrect.xmax= rect->xmin;
|
|
|
|
txtrect.ymax= rect->ymin;
|
|
|
|
|
|
|
|
/* clip is very strict, so we give it some space */
|
|
|
|
/* clipping is done without rotation, so make rect big enough to contain both positions */
|
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_clipping(fs->uifont_id, txtrect.xmin-1, txtrect.ymin-yofs-xofs-4, rect->xmax+1, rect->ymax+4);
|
|
|
|
BLF_enable(fs->uifont_id, BLF_CLIPPING);
|
|
|
|
BLF_position(fs->uifont_id, txtrect.xmin+xofs, txtrect.ymax-yofs, 0.0f);
|
2009-10-19 03:54:30 +00:00
|
|
|
|
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_enable(fs->uifont_id, BLF_ROTATION);
|
|
|
|
BLF_rotation(fs->uifont_id, angle);
|
2009-10-19 03:54:30 +00:00
|
|
|
|
|
|
|
if (fs->shadow) {
|
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_enable(fs->uifont_id, BLF_SHADOW);
|
|
|
|
BLF_shadow(fs->uifont_id, fs->shadow, fs->shadowcolor, fs->shadowcolor, fs->shadowcolor, fs->shadowalpha);
|
|
|
|
BLF_shadow_offset(fs->uifont_id, fs->shadx, fs->shady);
|
2009-10-19 03:54:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (fs->kerning == 1)
|
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_enable(fs->uifont_id, BLF_KERNING_DEFAULT);
|
2009-10-19 03:54:30 +00:00
|
|
|
|
2010-11-11 06:35:45 +00:00
|
|
|
BLF_draw(fs->uifont_id, str, 65535); /* XXX, use real length */
|
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_disable(fs->uifont_id, BLF_ROTATION);
|
|
|
|
BLF_disable(fs->uifont_id, BLF_CLIPPING);
|
2009-10-19 03:54:30 +00:00
|
|
|
if (fs->shadow)
|
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_disable(fs->uifont_id, BLF_SHADOW);
|
2009-10-19 03:54:30 +00:00
|
|
|
if (fs->kerning == 1)
|
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_disable(fs->uifont_id, BLF_KERNING_DEFAULT);
|
2009-10-19 03:54:30 +00:00
|
|
|
}
|
|
|
|
|
2009-04-10 16:30:28 +00:00
|
|
|
/* ************** helpers ************************ */
|
|
|
|
|
|
|
|
/* temporarily, does widget font */
|
2010-11-17 09:45:45 +00:00
|
|
|
int UI_GetStringWidth(const char *str)
|
2009-04-10 16:30:28 +00:00
|
|
|
{
|
|
|
|
uiStyle *style= U.uistyles.first;
|
2010-04-02 11:15:37 +00:00
|
|
|
uiFontStyle *fstyle= &style->widget;
|
|
|
|
int width;
|
2009-04-10 16:30:28 +00:00
|
|
|
|
2010-04-02 11:15:37 +00:00
|
|
|
if (fstyle->kerning==1) /* for BLF_width */
|
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_enable(fstyle->uifont_id, BLF_KERNING_DEFAULT);
|
2010-04-02 11:15:37 +00:00
|
|
|
|
|
|
|
uiStyleFontSet(fstyle);
|
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
|
|
|
width= BLF_width(fstyle->uifont_id, str);
|
2010-04-02 11:15:37 +00:00
|
|
|
|
|
|
|
if (fstyle->kerning==1)
|
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_disable(fstyle->uifont_id, BLF_KERNING_DEFAULT);
|
2010-04-02 11:15:37 +00:00
|
|
|
|
|
|
|
return width;
|
2009-04-10 16:30:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* temporarily, does widget font */
|
2010-11-17 09:45:45 +00:00
|
|
|
void UI_DrawString(float x, float y, const char *str)
|
2009-04-10 16:30:28 +00:00
|
|
|
{
|
|
|
|
uiStyle *style= U.uistyles.first;
|
|
|
|
|
2010-11-07 18:01:32 +00:00
|
|
|
if (style->widget.kerning == 1)
|
|
|
|
BLF_enable(style->widget.uifont_id, BLF_KERNING_DEFAULT);
|
|
|
|
|
2009-04-10 16:30:28 +00:00
|
|
|
uiStyleFontSet(&style->widget);
|
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_position(style->widget.uifont_id, x, y, 0.0f);
|
2010-11-11 06:35:45 +00:00
|
|
|
BLF_draw(style->widget.uifont_id, str, 65535); /* XXX, use real length */
|
2010-11-07 18:01:32 +00:00
|
|
|
|
|
|
|
if (style->widget.kerning == 1)
|
|
|
|
BLF_disable(style->widget.uifont_id, BLF_KERNING_DEFAULT);
|
2009-04-10 16:30:28 +00:00
|
|
|
}
|
2009-04-09 18:11:18 +00:00
|
|
|
|
|
|
|
/* ************** init exit ************************ */
|
|
|
|
|
2010-07-15 11:51:43 +00:00
|
|
|
/* called on each startup.blend read */
|
2009-04-09 18:11:18 +00:00
|
|
|
/* reading without uifont will create one */
|
|
|
|
void uiStyleInit(void)
|
|
|
|
{
|
|
|
|
uiFont *font= U.uifonts.first;
|
|
|
|
uiStyle *style= U.uistyles.first;
|
|
|
|
|
|
|
|
/* recover from uninitialized dpi */
|
|
|
|
CLAMP(U.dpi, 72, 240);
|
|
|
|
|
|
|
|
/* default builtin */
|
|
|
|
if(font==NULL) {
|
|
|
|
font= MEM_callocN(sizeof(uiFont), "ui font");
|
|
|
|
BLI_addtail(&U.uifonts, font);
|
|
|
|
|
|
|
|
strcpy(font->filename, "default");
|
|
|
|
font->uifont_id= UIFONT_DEFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
for(font= U.uifonts.first; font; font= font->next) {
|
|
|
|
|
|
|
|
if(font->uifont_id==UIFONT_DEFAULT) {
|
|
|
|
font->blf_id= BLF_load_mem("default", (unsigned char*)datatoc_bfont_ttf, datatoc_bfont_ttf_size);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
font->blf_id= BLF_load(font->filename);
|
|
|
|
if(font->blf_id == -1)
|
|
|
|
font->blf_id= BLF_load_mem("default", (unsigned char*)datatoc_bfont_ttf, datatoc_bfont_ttf_size);
|
|
|
|
}
|
2009-04-23 21:57:41 +00:00
|
|
|
|
2010-01-22 06:48:29 +00:00
|
|
|
if (font->blf_id == -1) {
|
|
|
|
if (G.f & G_DEBUG)
|
|
|
|
printf("uiStyleInit error, no fonts available\n");
|
|
|
|
}
|
2009-04-09 18:11:18 +00:00
|
|
|
else {
|
2009-04-23 21:57:41 +00:00
|
|
|
/* ? just for speed to initialize?
|
2009-05-05 23:10:32 +00:00
|
|
|
* Yes, this build the glyph cache and create
|
|
|
|
* the texture.
|
2009-04-23 21:57:41 +00:00
|
|
|
*/
|
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_size(font->blf_id, 11, U.dpi);
|
|
|
|
BLF_size(font->blf_id, 12, U.dpi);
|
|
|
|
BLF_size(font->blf_id, 14, U.dpi);
|
2009-04-09 18:11:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if(style==NULL) {
|
|
|
|
ui_style_new(&U.uistyles, "Default Style");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-04-10 14:06:24 +00:00
|
|
|
void uiStyleFontSet(uiFontStyle *fs)
|
|
|
|
{
|
|
|
|
uiFont *font= uifont_to_blfont(fs->uifont_id);
|
|
|
|
|
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_size(font->blf_id, fs->points, U.dpi);
|
2009-04-10 14:06:24 +00:00
|
|
|
}
|
|
|
|
|