BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
GCC seems to detect uninitialized into function calls now, but then isn't
always smart enough to see that it is actually initialized. Disabling this
warning entirely seems a bit too much, so initialize a bit more now.
- Adds support for word wrapping to Blender's BLF font library.
- Splits lines when width limit is reached or on explicit \n newlines.
Details:
- Word wrapping is used when `BLF_WORD_WRAP` flag is enabled.
- There is a single loop to handle line wrapping,
this runs callback, passing in a substring,
this way we can avoid code-duplication for all word-wrapped
versions of functions... OR... avoid having to add support
for word-wrapping directly into each function.
- The `ResultBLF` struct was added to be able to get the number
of wrapped lines, when calling otherwise unrelated functions
such as `BLF_draw/BLF_width/BLF_boundbox`,
which can be passed as the last argument to `BLF_*_ex()` functions.
- The `ResultBLF` struct is used to store the result of drawing
(currently only the number of lines wrapped, and the width).
Printing text on the color grid image would initialize font glyphs from a thread at
the same time as the UI, causing conflicts. The freetype glyph renderer needs to be
mutex locked because it uses a shared buffer internally even when rendering for
different fonts. Also needed to change the image generate function to use the render
monospace font to avoid conflicts in blenfont.
What's still weak in the blenfont API is that there is no distinction between a font
and a thread using that font to render with some particular size, style, etc.
old issue, the formulas here were never quite right, should all work ok now
with byte and float images.
Some differences:
* Colors with zero alpha from the background will never have an influence, so
you don't get alpha fringes when painting over such areas. This does give
hard edges when looking at the RGB channels alone, but there's no way to
avoid that and fringes at the same time, same behavior as other painting apps.
* Add/Subtract/Multiply/Lighten/Darken now leave the alpha channel unchanged
and work only the RGB channels, again same behavior as many other apps.
* Erase/Add alpha now compensates for premultiplied float images to keep the
straight RGB colors the same.
Next: fix projection painting.
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!
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
This is need to properly handle 3d text (dalai work on GE), before
the BLF_aspect only take one argument, and the result was a call to:
glScalef(aspect, aspect, 1.0)
Now the three value are store in the font (x, y and z) and also
need to be enable using BLF_enable(BLF_ASPECT).
By default all the code that don't have BLF_ASPECT enable work with
a scale of 1.0 (so nothing change to the current UI).
I also remove all the call of BLF_aspect(fontid, 1.0) found in
the editors, because is disable by default, so no need any more.
Campbell the only thing to check is the python api, right now
I modify the api to from:
BLF_aspect(fontid, aspect)
to:
BLF_aspect(fontid, aspect, aspect, 1.0)
This is to avoid break the api, but now you need add the BLF_ASPECT
option to the function py_blf_enable and in some point change
py_blf_aspect to take 3 arguments.
[#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.
