When a timer needs to execute during the idle time (currently 5ms), use
microsecond precision to ensure the timer isn't delayed by the idle
time.
This improves the precision of animation playback on systems that
support it
(WIN32, see note below).
In my tests FPS playback varied:
- 59.94 FPS would jitter between 58.13 & 63.11 FPS. 23.98 FPS would
- jitter between 23.68 & 24.31 FPS.
Using higher precision timers mostly resolves this issue although there
is still some jitter although it's now limited to ~0.01 FPS.
These values were measured with the FPS-Samples set to 1 to show the
real times between frames (without the values being smoothed out).
This is a continuation of a fix for #111579 which avoided the worst of
the jittering issues at higher frame rates.
It appears WIN32 doesn't support sleeping shorter than 1 millisecond via
`std::this_thread::sleep_for`, making this change have no benefit on
WIN32, from tests it also doesn't have any down sides, so avoid platform
specific logic. The WIN32 limitation is noted in code-comments. If a
method of higher precision method is available this can be investigated.
Setting the FPS to 120 caused the FPS to flicker erratically between
130 & 140 FPS.
This also impacted lower frame-rates with 23.98 playing back at 24.03
FPS on my system, 30 FPS played back at 30.13 FPS.
This problem was hidden by the FPS display rounding to an integer.
Regression in 2.5x series (worked in 2.49).
Resolve by clamping the sleep time in the main event loop so the 5ms
sleep doesn't result in sleeping when timers are scheduled to run.
There is still some visible FPS jitter that can be solved by using a
higher resolution sleep interval but that's out of scope for this fix.
This adds a new Ghost function, GHOST_GetPixelAtCursor, that allows
picking colors from outside of Blender windows. This only has an
implementation for the Windows platform, but this should allow other
platforms to also do so if possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/105324
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
