Commit Graph

7 Commits

Author SHA1 Message Date
Campbell Barton
4fa3dc0dd4 Cleanup: spelling in comments, use uppercase tags 2024-10-03 12:11:52 +10:00
Campbell Barton
381898b6dc Refactor: move BLI_path_util header to C++, rename to BLI_path_utils
Move to a C++ header to allow C++ features to be used there,
use the "utils" suffix as it's preferred for new files.

Ref !128147
2024-09-26 21:13:39 +10:00
Campbell Barton
9b39b4c91c Cleanup: use const pointers/references 2024-09-15 23:14:09 +10:00
Aras Pranckevicius
649cde421b Fix #127468: VSE thumbnail cache related crash when quitting blender
Do not try to kill thumbnail generation job when destroying the cache
(which happens as part of destroying the scene) -- all the code
paths that destroy a scene already cancel outstanding WM jobs. And WM
itself might be gone at that point, so accessing a stale pointer to it
can lead to a crash.

Instead, fix the problem of "refresh sequencer can cause a crash" by
not destroying the thumbnail cache, but merely clearing it in
sequencer_refresh_all_exec.

Pull Request: https://projects.blender.org/blender/blender/pulls/127485
2024-09-12 14:48:20 +02:00
Aras Pranckevicius
4c8f22447f VSE: Faster timeline thumbnail drawing
VSE timeline, when many (hundreds/thousands) of thumbnails were visible, was
very slow to redraw. This PR makes them 3-10x faster to redraw, by stopping
doing things that are slow :) Part of #126087 thumbnail improvements task.

- No longer do mute semitransparency or corner rounding on the CPU, do it in
  shader instead.
- Stop creating a separate GPU texture for each thumbnail, on every repaint,
  and drawing each thumbnail as a separate draw call. Instead, put thumbnails
  into a single texture atlas (using a simple shelf packing algorithm), and
  draw them in batch, passing data via UBO. The atlas is still re-created every
  frame, but that does not seem to be a performance issue. Thumbnails are
  cropped horizontally based on how much of their parts are visible (e.g. a
  narrow strip on screen), so realistically the atlas size is kinda
  proportional to screen size, and ends up being just several megabytes of data
  transfer between CPU -> GPU each frame.

On this Sprite Fright edit timeline view (612 visible thumbnails), time taken
to repaint the timeline window:

- Mac (M1 Max, Metal): 68.1ms -> 4.7ms
- Windows (Ryzen 5950X, RTX 3080Ti, OpenGL): 23.7ms -> 6.8ms

This also fixes a visual issue with thumbnails, where when strips are very
tall, the "rounded corners" that were poked right into the thumbnail bitmap
on the CPU were showing up due to actual bitmap being scaled up a lot.

Pull Request: https://projects.blender.org/blender/blender/pulls/126972
2024-09-03 08:25:15 +02:00
Campbell Barton
4ed0d9f30e Cleanup: spelling in comments 2024-08-29 17:16:42 +10:00
Aras Pranckevicius
528471541b VSE: Faster and more consistent thumbnails
Implementing part of design outlined in #126087.

- VSE thumbnail cache has a new implementation, hopefully simpler
  and easier to understand.
    - Instead of cache key being a VSE strip, frame index, plus
      complicated logic for cache items linking etc.,
    - The cache is keyed by media file path (if multiple strips
      use the same input file, they will share cache entries), frame
      index within media file, and any extra data (e.g. steam index
      for multi-steam videos)
- Much reduced cache flickering and strange/weird thumbnail choices.
    - Likewise, thumbnails no longer disappear-and-reload on operations
      like Undo, dragging new video strip into timeline, or F12 render.
- Thumbnails now load faster.
    - Images use dedicated/faster thumbnail loading routines when a
      format can do that (e.g. JPG and EXR can).
    - Movies reuse ffmpeg decoding context for neighboring strips
      that use the same file (as often happens when cutting footage)
    - Thumbnail requests are processed on several threads now too.

Images and more detail in PR.

Pull Request: https://projects.blender.org/blender/blender/pulls/126405
2024-08-29 08:27:12 +02:00