We needed the 'background' feature here, since we never wait on those preview-generation tasks.
Note that it also simplifies the code, and as usual testing is needed here on all possible platforms...
Using the global scheduler here is not a really good idea - `filelist_cache_previewf()` is not a short task
that run once, but it's a loop that keeps cheking for work in a TODO queue. This means it won't quickly allow other tasks
to start, so it should not be in the global scheduler.
In fact, asynchronous tasks (that is, tasks that will live for quite a bit of time, and often sleep a lot) should never use
global scheduler, they would steal computing resources from heavy-duty, short-time living ones - and possibly even completely
stall threaded tasks (if all worker threads are executing long-life tasks...).
We could probably even completely bypass the scheduler/task thing here (and directly use threads), but it does not have
that much of an over-head, and still offers easy handling of threading stuff...
We were still using main borwser's FileDirEntryArr to own memory of entries currently in cache.
That was OK for common caching operation, but if was not released when clearing cache!
Nothing dramatic, since that was cleared too, but less often, so e.g. by changing sorting
options you could pile up more and more no-more-used entries there...
Anyway, there is no reason to do that, much more sound and clean to keep everything
cache-related in dedicated FileDirEntryCache struct.
This means main borwser's FileDirEntryArr is now always expected to not store any actual entry!
Note: this can probably be cleaned up a bit more, but would wait after 2.76 for this!
An entry could already exist in misc cache, when creating it for block cache, leading to double-creation.
Issue was not that serious (no memleak or so), but nasty still. Thanks to Severin for notifying the assert.
It basically rewrites most of filelist.c, with some more limited changes in other areas of filebrowser.
From user perspective, it:
* Removes some info in 'long' drawing mode (owner, permissions) - OS-specific data that do not really matter in Blender!
* Makes short/long display 'fixed' size (among four choices, like thumbnails mode).
* Allows to list several layers of dirtree at once, in a flat way (inside .blend files and/or real directories).
* Consequently, adds datablocks types filtering.
* Uses way less RAM when listing big directories, especially in thumbnail mode (we are talking of several hundred of MiB spared).
* Generates thumbnails way faster.
From code perspective, it:
* Is ready for asset engine needs (on data structure level in filebrowser's listing).
* Simplifies and makes 'generic' file listing much lighter.
* Separates file listing in three different aspects:
** 'generic' filelisting (in BLI), which becomes a shallow wrapper around stat struct.
** 'filebrowser drawing' filelisting, which only contains current visible subset of the whole list (sliding window), with extra drawing data (strings for size, date/time, preview, etc.).
** 'asset-ready' filelisting, which is used for operations common to 'basic' filehandling and future asset-related one.
* Uses uuid's to handle file selection/state in the browser, instead of using flags in filelisting items.
* Uses much lighter BLI_task handling for previews, instead of heavy 'job' system (using the new 'notifier' timer to handle UI refresh, in similar way to jobs).
* Moves .blend datablocks preview handling to IMB_thumbnail (necessary to avoid storing all datablock previews at once, and gives better consistency and performances too).
Revision: https://developer.blender.org/D1316
Thanks to Campbell & Sergey for the reviews. :)
For areas that require append, store the last node,
Previous behavior would too easily hide poorly performing code.
Also avoid (prepend, reverse) where possible.
We can now scale from 32px up to 256px (default has been upgraded to 128px).
Thumbnails are now generated as 'large', i.e. 256px.
Previews are scaled up if necessary, unlike icons (for folders or files without preview images).
Note that .blend thumbnails themselves remain in 128px for now (they are embeded in .blend files,
not quite sure we want to make them four times bigger...).
Patch by DMS (Yaron Dames), with final edits by myself.
Reviewers: mont29
Subscribers: Severin, mont29
Differential Revision: https://developer.blender.org/D1260
On windows empty dirs are completely empty - no par or current entries
are listed either, in those cases artificially add those.
Furthermore, stat on UNC paths do not support current/parent 'shortcuts'
(i.e. things like '\\SERVER\foo\bar\..' do not work), so we have to hack
around that mess...
This should ensure us we always do have valid parrent entry...
Was only handling failures in video thumbnails, was confusing (giving two different types
for video files, *sigh*), and... useless, since thumbnail code already handles smartly
failures in preview generation!
D1002 by @plasmasolutions, with own refactoring.
Note, needed to do a bad-level call here (IMB -> BLF)
Also can't use the BLF API directly because its not thread-safe.
So keep the function isolated (blf_thumbs.c).
Do not allow going into un-readable directories at all.
Note we might want to reflect that 'state' in UI for users too, but that will be
for later.
Also, not quite sure this fix the windows case, will have to start my VM... :/
New code shall be more easy to maintain and extend.
Sorting is now handled quite the same as filtering, and all filtering parameters
are now packed into a sub-struct to help extending it later.
Also done some optimizations in filelist refresh, and sorting/filtering area.
Now we should avoid re-sorting and re-filtering too often, also removed
calls to those in read_xxx funcs.
Note thumbnail job is still started basically on each call to `file_refresh()`,
will be addressed in next commit.
