Adds support for saving some view state persistently and uses this to keep the
height of a tree-view, even as the region containing it is hidden, or the file
re-loaded.
Fixes#129058.
Basically the design is to have state stored in the region, so it can be saved
to files. Views types (tree-view, grid-view, etc) can decide themselves if they
have state to be preserved, and what state that is. If a view wants to preserve
state, it's stored in a list inside the region, identified by the view's idname.
Limitation is that multiple instances of the same view would share these bits of
state, in practice I don't think that's ever an issue.
More state can be added to be preserved as needed. Since different kinds of
views may require different state, I was thinking we could add ID properties to
`uiViewState` even, making it much more dynamic.
Pull Request: https://projects.blender.org/blender/blender/pulls/130292
This is a more invasive change to the timecode indexer because ffmpeg removed the ability to to get the `pkt_pos` (byte location of a frame packet):
27f8c9b27b
As stated there, they don't think that using it too seek is any better than using the dts or the pts position of the packets.
While you can still seek with the byte position, you need to do quite a bit of extra work to get this information from ffmpeg.
As we are only using it for the indexer and only if the fileformat was quite old (mpegts etc) I thought that we could instead simplify this and always seek by the pts timestamp instead.
Pull Request: https://projects.blender.org/blender/blender/pulls/130444
Recently the GLSL code was changed in Blender. For every GLSL file
the #line directive was added. However due to limitations in Blender
we misuse the indexed based line directive to store a hash. This is not
according to the spec where indexes should index the source inside the
array of sources. In vulkan the indexed based approach is not
'supported' as the compiler inputs only accepts a single file.
We tried to support file based approach but that lead to other issues in
renderdoc. Might be related to that the source file doesn't exist on the
file system.
This PR fixes this by scrambling the #line directive so the
step-by-step debugger can be used. The scrabling only happens when
blender is started with the `--debug-gpu-renderdoc` startup argument.
Pull Request: https://projects.blender.org/blender/blender/pulls/130458
Allow passing range of resources inside the draw manager.
This allows to reduce the overhead of the drawing logic
for group of instances sharing the same drawing state.
The only catch is that we do consider them as having the
same handedness, which seems to be a valid assumption for
now.
For now this is not used and just change the API in a transparent
way to allow incremental changes to the engines code.
Pull Request: https://projects.blender.org/blender/blender/pulls/130290
RNA accessors should never (ever?) modify the `owner_id` of their parent
PointerRNA data. This is opening a potential monstruous can of worms.
If such behavior is absolutely needed, there should be a very detailed
comment about why!
In the present case, this does not seem needed at all - and was most
likely fairly harmless in practice.
Filling the background Box of a text strip was a single-threaded
code before. Which was pretty fast for a simple rectangle, but
when roundness is used it becomes a bit slower (super-ellipse
equation has to be evaluated for each pixel in the rounded corners,
which is 3x powf per pixel).
So make the background box use multi-threading. On M1 Max, filling
background box of 2256x1691 pixels:
- No roundness: 25.8ms -> 4.3ms
- Roundness 0.3 (253 pixels): 31.9ms -> 5.8ms
- Roundness 1.0 (845 pixels): 94.6ms -> 15.8ms
Pull Request: https://projects.blender.org/blender/blender/pulls/130403
The issue was that if the evaluated object doesn't have an active
layer, the canvas is offset by twice the objects position.
The reason was that the code scaled the whole transformation
matrix by two to match the code in 4.2, but then had to overwrite
the location of the transformation again to counteract the scaling.
The fix is to not counteract the scaling and just scale the 3x3 part
of the matrix instead. This way we can remove the part afterwards
that writes to the location of the transform.
Pull Request: https://projects.blender.org/blender/blender/pulls/130454
For flat caps, only one point is added in data.positions array for
endpoints of stroke. It results in incomplete outline. To resolve
this, add another point in new curves at the exact opposite position.
Pull Request: https://projects.blender.org/blender/blender/pulls/130437
Since all legacy Grease Pencil modifier are converted to regular modifiers
in versioning, we should never be in a position where we need to write the
old modifiers anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/130388
When points are close together in 2D view space the eraser intersection
function does not have a valid direction vector (zero). This cancels out
terms in the computation that would still contribute to the result and
the function always returns zero intersections.
This patch adds a special case when the direction vector is zero,
so the point distance to the circle is still calculated (just not in
any particular direction).
Pull Request: https://projects.blender.org/blender/blender/pulls/130341
While copying `PointerRNA` struct is currently extremely cheap, this
won't be the case in the future once it starts storing more complex
data.
Keeping an independent copy in `PropertyRNAOrID` struct should never be
needed, as this is a fairly short-lived runtime data, so store a pointer
to the given PointerRNA instead.
Properties that are animated, but have different values than their
animation data, are drawn in orange. This was skipped whenever any NLA
tracks were active (likely because this would re-evaluate the NLA for
every property drawn, which is a performance bottleneck).
This commit lifts this limitation slightly, and only skips the "has this
changed?" check if there are any non-muted NLA tracks. This means that
using the NLA purely as a stash of Actions is now possible without
losing the 'orange means it changed' indicators in the UI.
Fixes: #129968
Pull Request: https://projects.blender.org/blender/blender/pulls/130130
This is not implemented yet so remove the callback function which draws
channel color for GPv3 layers. Also `acf_gpl_channel_color` is a legacy function,
it may lead to different channel color as explained in #130370.
Pull Request: https://projects.blender.org/blender/blender/pulls/130445
The issue was that when the fill strokes were merged into the drawing,
the `fill_opacity` attribute would be created on the drawing
(when it didn't exist before) and initialized to 0. This meant that
all previously drawn fill strokes would disappear.
The fix manaully initializes the `fill_opacity` attribute on the
target geometry before calling `join_geometries`.
Ideally this could be something the attribute system handles
or the `join_geometries` function takes care of by getting
some information about how to initialize attributes.
Pull Request: https://projects.blender.org/blender/blender/pulls/130442
Tell ffmpeg swscale to do accurate YUV->RGB conversion, instead of
slightly faster but not really accurate one. Fixes banding and some
color shifts in video files, particularly in dark regions.
The accurate conversion is a bit slower though, on 4K resolution video,
time taken to convert video frame from YUV to RGB:
- x64 (Ryzen 5950X): 2.3ms -> 3.7ms
- arm64 (M1 Max): 0.6ms -> 2.9ms
My take is that paying 1-2ms per 4K video playback is acceptable
since the result is obviously "more correct" and matches what VLC/ffplay
produces.
From what I can tell, "accurate conversion" turns off some dedicated
assembly code paths within ffmpeg. Maybe someday ffmpeg would get
accurate and assembly-optimized routines for that.
With more accurate decoding, we can now lower the expected render
test threshold again, since x64 & arm64 decoding is much closer now.
Comparison screenshots in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/130383
While adding test coverage for in-memory and packed texture scenarios, I
found that UDIMs were not being handled correctly in both cases. For
in-memory scenarios the per-tile generated/dirty status was not taken
into account. For packed scenarios the wrong filename substitutions were
being used.
This fixes both of these cases and adds test coverage for these
scenarios now. Both relative and absolute path options are validated.
Note: Both in-memory and packed images behave incorrectly when using the
'KEEP' and 'PRESERVE' texture export modes, so those remain untested
currently. A design on exactly what should happen in these modes is TBD.
Pull Request: https://projects.blender.org/blender/blender/pulls/130391
This only happened if there are multiple different resource
handle used inside the same `PassSimple`.
Fix is to use the same logic to find the first instance.
Fix#130384
