| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Byte images used `ibuf->float_colorspace` as source colorspace.
This was oversight - `ibuf->rect_colorspace` should be used as source
colorspace.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11223
|
|
|
|
|
|
This was never used (since 2.25 at least).
|
|
|
|
|
|
Error in 0499dbc5c16fe6b276da81d65cade4f5da92a308
|
|
|
|
This functionality was missed in recent GLSL drawing update
fd3e44492e7606a741a6d2c42b31687598c7d09a.
|
|
|
|
|
|
|
|
|
|
Instead of only drawing images on first start, load them into cache.
This resolves a logical problem when images don't load fast enough,
where the animation would load some frames each time until all images
loaded into cache.
In practice this could play back with severe frame skipping many times
times before all images were loaded making playback smooth.
Part of a fix for T81751.
|
|
|
|
|
|
Resizing the window would always draw the image with an empty imbuf.
|
|
|
|
|
|
Originally colorspace of float images was converted using CPU.
GLSL will render images much faster.
Originally image was converted to `global_role_default_byte` space,
disregarding view transform and also display device, which now is
possible to specify. These parameters could be set via commandline to
settings used in Blender, however if they are to be set by users, these
needs to be sanitized.
Right now defaults are assumed for device given for
`COLOR_ROLE_DEFAULT_BYTE`. This should produce same behavior as
implemented before.
Together with D11167 animation player performance should be much better.
This code was mostly copy-pasted from sequencer.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11178
|
|
Naming was inconsistent and hard to follow.
|
|
|
|
Partial fix for T81751 which exposes multiple playback performance
issues. Previously the cache was limited to 30 frames, without a way to
increase the cache for smooth playback with files that are slow to load.
Now the animation plays back smoothly once loaded into cache.
The cache limit from the system preference is used
when the player is launched from Blender.
A new player argument `-c <cache_limit>` was added to support this.
|
|
|
|
Each frame display would add an item to the cache limiting list
without checking if it was already in the list.
Limiting would then free image buffers when the length of the list
exceeded USE_FRAME_CACHE_LIMIT (currently 30).
In practice this meant short animations would free and reload
frames during playback.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 9cce18a5858cb93da626f5f0fd7e09cd66637e05.
rB9cce18a5858c broke the build in unforeseen ways, not easily fixable.
revert for now, so master will at least build again.
|
|
I'm currently doing some experiments in the info editor and
for that it is easier if the info editor is in c++ already.
|
|
|
|
- Re-order freeing so an instances __del__ method runs before the
`ExtensionRNA` has been freed.
- "remove" functions no longer free the gizmo/gizmo-group memory,
needed so the identifier used when freeing the extension
doesn't use the freed identifier.
|
|
|
|
If saving a file using CloseSave dialog, do not close if there is an error doing so, like if read-only.
Differential Revision: https://developer.blender.org/D10722
Reviewed by Julian Eisel
|
|
Was showing a simple confirm dialog, even if the file didn't contain
unsaved changes. The confirm dialog would also show up when choosing
"Restore Last Session" from the splash screen right after startup, which
is weird.
Instead show the proper file closing dialog that allows saving, but only
if there are actually unsaved changes.
|
|
Was doing almost the same thing in two places, plus I need the same for
a third case. So better have a helper function for it.
|
|
Makes it less of a hassle to pass these callbacks around as function
arguments, and deduplicates their signature when doing so.
|
|
Call this function instead of `CTX_wm_operator_poll_msg_set(C, NULL)`
|
|
Prevent drag events from changing the highlighted gizmo
unless the drag event activates the gizmo.
This resolves a glitch where testing a drag event would highlight
at the point the drag was initiated even when the event was not handled.
|
|
Non-functional change in preparation for fix.
|
|
gizmo_button2d_bounds result wasn't valid when the gizmo was part
of a 3D gizmo group.
Regression in cf6d17a6aa421e0038fc1f8e60e3f1f708887c3e
|
|
This prevented dynamic enum callbacks being called.
|
|
Tweak and click-drag events already apply this offset, this was a no-op.
|
|
Click-drag events that weren't handled would continually be tested
for each mouse-motion event.
As well as being redundant, this added the overhead of querying
gizmos twice per motion event.
Now click-drag is only tested once when the drag threshold is reached.
This mitigates T87511, although the single drag test still causes
the snap gizmo to flicker.
|
|
Keymap UI and import/export could depend on the current
context for dynamic enum's.
Use STRUCT_NO_CONTEXT_WITHOUT_OWNER_ID for OperatorProperties.
|
