- fix: user pref, window title was reset to 'Blender' on tab usage
- Undo history menu back:
- name "Undo History"
- hotkey alt+ctrl+z (alt+apple+z for mac)
- works like 2.4x, only for global undo, editmode and particle edit.
- Menu scroll
- for small windows or screens, popup menus now allow to display
all items, using internal scrolling
- works with a timer, scrolling 10 items per second when mouse
is over the top or bottom arrow
- if menu is too big to display, it now draws to top or bottom,
based on largest available space.
- also works for hotkey driven pop up menus.
- User pref "DPI" follows widget/layout size
- widgets & headers now become bigger and smaller, to match
'dpi' font sizes. Works well to match UI to monitor size.
- note that icons can get fuzzy, we need better mipmaps for it
* they were too slow for dynamic python enums, calling the callback
to list the items for each button, to get a tooltip
* enum tooltips sometimes were showing the same description twice
mouse coords would with cont. grab would wrap at short.
use mouse coords as int rather then short.
this problem still happens on linux because of XTranslateCoordinates
- ghost C api, BLI_get_folder_version() could assign garbage values.
- pointcache ptcache_find_frames_around() had a superfluous NULL check which would have crashed anyway if actually NULL.
Disable this for pointer buttons since this was intended for vgroups & uvlayers.
Pointer buttons often reference ID's which can be in the 1000+, lookups like this on each button draw is not useful since invalid pointers here will likely crash on scene evaluation.
most local modifier,GPU,ImBuf and Interface functions are now static.
also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
- modifier code was using sizeof() without knowing the sizeof the array when clearing the modifier type array.
- use BLI_snprintf rather then sprintf where the size of the string is known.
- particle drawing code kept a reference to stack float values (not a problem at the moment but would crash if accessed later).
Report was that move-to-layer menu failed. The real cause was
more complex; had to dive deep in the dungeons of the interface
code that handled undos and operators. Found several issues:
- popup menus (like redo operator, color picker) executed again
on a mouse-exit
- far too many buttons were sending undo pushes; even worse, in
the operator redo-panel each button action was pushed twice
- in case operator redo-buttons have own callbacks (like layer
buttons) the redo wasn't working
- layerbutton menu was called without creating a proper undo/redo
case
Things should all work smoother now!
On todo:
- better definition and handling of all versions for operator menus
(four types now, not fun)
also: make operator "do" menu, which on first action does operator
and then switches to redo-ing
- bring back Undo menu, to list the undo stack and jump in it.
UI name buttons with Search callback show red when item couldn't be
found. The check was too simple though, since the searches also find
partial matches. This caused KeyingSet browse to show red for "RotScale".
Now 10 matches are stored, and each match is being checked. Still a
bit weak for cases with more than 10 matches, but in that case it
won't show red-alert.
[#25159] Vertex locations dont read correctly and are not labeled correctly in the properties bar.
- non rna buttons can now have units set.
- calls with invalid units system now raises an assert().
- include .mxf in filter.
Also use const char in many other parts of blenders code.
Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
WM_operator_poll() could fail in cases WM_operator_name_call() would succeed because calling the operator would setup the context before calling poll.
this would result in python raising an invalid error or menu items being greyed out.
now python can also check with an operator context:
bpy.ops.object.editmode_toggle.poll('INVOKE_SCREEN')
- made interface, windowmanager, readfile build without unused warnings.
- re-arranged CMake's source/blender build order so less changed libs are build later, eg: IK, avi
- use FTOCHAR macro which clamps values above 1.0 (rather then wrapping)
- also fixes a problem rounding down where white would display as FEFEFE rather then FFFFFF
the report also mentions how editing colors above 255 is broken but think this isnt worth trying to support.
Use: 1 + ((lift-1) * (lift-1)) so 2.0 is still a full lift but 1.x isnt so strong.
Changed color picker to give more precission, we were having to edit the buttons to see what the numbers were.
Small change to keep the value of H and S when V come to zero, take care
that only work if you keep the color picker open.
When the color picker is closed, the H and S value are reset to zero
this is because the color picker is used in a lot of different place
and this value need to be reset.
(BTW reset to zero only when V is equal to zero!)
[#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.
This fixes only the crash, which was due to buffer overrun for col Hex char buffer. It doesn't actually fix the real issue of overflowing the color values up to infinity.
