[vlc-devel] [PATCH v2 00/13] Execute medialib queries out of the UI thread

[Pierre Lamot]

On 2020-11-26 17:54, Romain Vimont wrote:
> On Thu, Nov 26, 2020 at 05:10:32PM +0100, Romain Vimont wrote:
>> v1: 
>> https://mailman.videolan.org/pipermail/vlc-devel/2020-November/140488.html
>> 
>> Changes since v1:
>>  - fix ListCacheBase/BaseListCache rename in the middle of the 
>> patchset
>>    (patches 5 and 11)
>>  - fix crash on thumbnail generated if there is no cache (patch 6)
>>  - make "internal" Runnable an inner-class private to AsyncTask (patch 
>> 10)
>>  - remove useless includes (patch 11)
>>  - change members visibility (patch 5)
> 
> I forgot to give a status about the remaining work listed in v1:
> 
>> There is still some work related to asynchronous loading:
>> - the UI should show that some background tasks are running (to let 
>> the user
>>   know that the visible data is not up-to-date)
> 
> I added (on a local branch) a property/signal/slot on the model to know
> if something if some loading is pending. I don't know how we want to
> present that in the UI, so nothing is plugged to it for now.

On the network views we have a spinner while the view is initially 
loading, we can probably have something alike when getting the initial 
count, though I expect it to take an order of magnitude less than 
network queries, maybe we can leave it empty.

for individual items maybe we can have a simple placeholder while the 
item is loading, bit like what youtube is doing [1], we should probably 
expose a "loading" property telling the view whether the actual 
properties can be accessed or if the placeholder should be shown 
instead.

[1] https://i.imgur.com/s99FGrb.png

>> - a "cache miss" item should be designed (currently, it shows "unknown
>>   name" with a cone)
> 
> How should we present that? I think a small circle/loading icon for 
> each
> item would be fine.
> 
>> - the cache strategy is suboptimal (if items of consecutive cache
>>   pages are visible simultaneously, the cache will invalidate its data
>>   on each refresh);
> 
> It's not a priority for now, it "works".
> 
>> - there are still "small" freezes sometimes (~250ms), but not always, 
>> when
>>   updating the UI list once the database query result is available; it
>>   requires more investigations
> 
> I'm currently investigating. There are also other SQL accesses from the
> main thread (in network/ for example, I don't know if it's related).
> 
>> - the list model abstract class (MLSlidingWindowModel) is templated, 
>> causing
>>   big compilation times on every change (which probably does not work 
>> the cost,
>>   since the concrete classes use QVariant to expose the data to Qt 
>> anyway)
> 
> I've changed that locally. I will propose a separate patchset later.
> 
> Regards
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel