@Mark: Sorry, that was probably a bit confusing. ;-)
What I meant was the following: Whenever a new batch of images are received
I resize and compress them a little bit to create thumbnails. After the
images are resized and compressed, they are added to the ListModel. That's
the part, that is still performed in the main thread.
In the delegate I am now using a QQuickAsyncImageProvider to dispatch the
painting to different threads. As the images are already correctly sized at
this point no resizing needs to be done in the image provider. So instead
of constantly resizing the images to the correct size in the image provider
I resize them once after I receive them.
The scrolling works fine now, but now the ListView lags a bit when a new
batch of images are received and processed. My initial idea was to
completely move the adding/removing (and the inital image processing) of
elements to a different thread, but I wasn't sure if that is safe. Because
in that case I would need to access the ListModel from two different
threads which probably isn't safe and won't work.
So I think my best bet is to use something like @Andy suggested and move
the QImage processing to another thread. After the image processing is done
the result gets copied back to the main thread and the image gets added to
the ListModel.
I think that's the same approach you also had in mind, right? :)
@Andy: Many thanks for the code snippet, that looks really promising. Will
definitely try that out!
Bernhard
2017-08-13 23:42 GMT+02:00 Mark Gaiser <mark...@gmail.com>:
> Hi,
>
> I don't quite follow.
>
> First you say you implemented our suggestions (move image processing in a
> thread), then you say: "all operations are performed in the main (GUI)
> thread"... Exactly the opposite of what we've been suggesting.
>
> If i'm reading your reply correctly you're not offloading anything to a
> separate thread ;)
> Do that and the listview will feel a lot more performant.
>
>
>
> On Sun, Aug 13, 2017 at 10:40 PM, Bernhard B <schluc...@gmail.com> wrote:
>
>> Many thanks guys!
>>
>> I just implemented your suggestions and have to say that the scrolling
>> performance definitely improved a lot. Thanks a lot for your help!
>>
>> However, as I am now doing more work (compress image + resize) before I
>> populate the Listmodel, I noticed that there is a significant lag every
>> time I fetch and process another batch of images from the server. I think
>> that's due to the fact that all operations are performed in the main (GUI)
>> thread.
>>
>> Does anyone know if it's possible to move the populating of the ListModel
>> to another thread? I am aware of the WorkerScript concept, but as far as I
>> know this only works for QML ListModel's and not for
>> QAbstractListModel-derived models. Or is the only possibility to move the
>> heavy lifiting (i.e image operations) to a separate thread and keep the
>> rest in the main thread? (as Mark suggested)
>>
>> Thanks,
>> Bernhard
>>
>>
>>
>>
>> 2017-08-11 15:54 GMT+02:00 Andy <asmalo...@gmail.com>:
>>
>>> I've been using jpeg - something like this (where MAX_THUMB_DIM is 60):
>>>
>>> void _saveThumbnail( QImage inImage, const QString &inPath )
>>> {
>>> QImage image = inImage.scaled( MAX_THUMB_DIM, MAX_THUMB_DIM,
>>> Qt::KeepAspectRatio, Qt::SmoothTransformation );
>>>
>>> QImageWriter writer( inPath, "JPEG" );
>>>
>>> writer.setQuality( 100 );
>>> writer.setOptimizedWrite( true );
>>> writer.setProgressiveScanWrite( true );
>>>
>>> writer.write( image );
>>> }
>>>
>>> It gives me decent-looking, reasonable sized thumbnails.
>>>
>>> ---
>>> Andy Maloney // https://asmaloney.com
>>> twitter ~ @asmaloney <https://twitter.com/asmaloney>
>>>
>>>
>>> On Fri, Aug 11, 2017 at 9:36 AM, Bernhard B <schluc...@gmail.com> wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> many thanks for your response! I am also using a
>>>> QAbstractListModel-derived class that gets exposed to the QML world which
>>>> contains the images.
>>>>
>>>> Yesterday I started to resize the images before feeding them to the
>>>> ListModel. According to the QML Profiler the delegate gets now created a
>>>> little bit faster, but fast scrolling is still a little bit sluggish. Today
>>>> I probably will play a little bit with different image codecs to see if
>>>> those have an impact. Currently I am using *.png files often which is
>>>> probably not the best choice.
>>>>
>>>> Thanks a lot for your input, really appreciated!
>>>>
>>>> Bernhard
>>>>
>>>>
>>>> Am Freitag, 11. August 2017 schrieb Andy :
>>>>
>>>>> Bernhard:
>>>>>
>>>>> I don't use QML, but in my application I use a
>>>>> QAbstractItemModel-derived class and a QTreeView-derived class to display
>>>>> image thumbnails in the view. The way I make it speedy is to save the
>>>>> image
>>>>> as a thumbnail so the view items don't need to resize the image data at
>>>>> all.
>>>>>
>>>>> Maybe you could save a thumbnail of an appropriate size when you're
>>>>> adding them to your model?
>>>>>
>>>>> ---
>>>>> Andy Maloney // https://asmaloney.com
>>>>> twitter ~ @asmaloney <https://twitter.com/asmaloney>
>>>>>
>>>>>
>>>>> On Fri, Aug 11, 2017 at 3:33 AM, Bernhard B <schluc...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Vlad,
>>>>>>
>>>>>> you mean the QQuickAsyncImageProvider? That one sounds really
>>>>>> promising. Will definitely try that out. Many thanks for the suggestion!
>>>>>>
>>>>>> Bernhard
>>>>>>
>>>>>> Am Donnerstag, 10. August 2017 schrieb Vlad Stelmahovsky :
>>>>>>
>>>>>>> threaded image provider might help
>>>>>>>
>>>>>>> On Thu, Aug 10, 2017 at 12:36 PM, Bernhard B <schluc...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> yesterday, I also tried to replace the Base64ImageProvider approach
>>>>>>>> with a subclassed QQuickPaintedItem which paints the image in it's
>>>>>>>> paint
>>>>>>>> method. I imagined that this approach might be faster es no bade64
>>>>>>>> decoding
>>>>>>>> needs to be done. But unfortunately it looks like as it's performing
>>>>>>>> even
>>>>>>>> worse that way.
>>>>>>>>
>>>>>>>> Bernhard
>>>>>>>>
>>>>>>>> Am Mittwoch, 9. August 2017 schrieb Bernhard B :
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I would need some help from you guys on how to improve the
>>>>>>>>> ListView's performance. The problem is, that scrolling through my
>>>>>>>>> ListView
>>>>>>>>> sometimes feels a little bit sluggish.
>>>>>>>>>
>>>>>>>>> If I only display some text in the ListView's delegate I can
>>>>>>>>> scroll smoothly through my list. But as soon as there is a picture in
>>>>>>>>> the
>>>>>>>>> ListView's delegate I notice that I can't scroll smoothly through my
>>>>>>>>> list
>>>>>>>>> anymore. That's especially noticable if I try to scroll fast through
>>>>>>>>> my
>>>>>>>>> list. Every time I hit a picture while scrolling through the list I
>>>>>>>>> can see
>>>>>>>>> that there is a noticable delay until the picture is fully loaded. My
>>>>>>>>> assumption is, that those pictures are the reason why he scrolling
>>>>>>>>> feels so
>>>>>>>>> sluggish.
>>>>>>>>>
>>>>>>>>> My application currently works like this:
>>>>>>>>>
>>>>>>>>> * load 20 pictures via REST (pictures are base64 encoded)
>>>>>>>>> * populate list model
>>>>>>>>> * the Image component in the delegate uses a Base64ImageProvider
>>>>>>>>> (self written) to access the model's base64 encoded content and
>>>>>>>>> displays
>>>>>>>>> the image
>>>>>>>>> * if the user scrolls past a threshold another batch of base64
>>>>>>>>> encoded pictures is fetched from the server
>>>>>>>>>
>>>>>>>>> I also found this document: http://doc.qt.io/qt-
>>>>>>>>> 5/qtquick-performance.html#rendering and tried to apply as much
>>>>>>>>> as possible. In detail I applied the following changes:
>>>>>>>>>
>>>>>>>>> * removed complex bindings from delegate
>>>>>>>>> * set sourceSize property for Image
>>>>>>>>> * increased cacheBuffer a bit
>>>>>>>>> * profiled with QML profiler and improved a few things
>>>>>>>>>
>>>>>>>>> But still, the ListView feels a bit sluggish. The strange thing
>>>>>>>>> is, that it's most noticable on Android whereas on Windows and iOs it
>>>>>>>>> is
>>>>>>>>> better.
>>>>>>>>>
>>>>>>>>> Does anyone have an idea on how to improve that?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Any help is really appreciated.
>>>>>>>>> Thanks a lot!
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Interest mailing list
>>>>>>>> Interest@qt-project.org
>>>>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Vlad
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Interest mailing list
>>>>>> Interest@qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>>
>>>>>>
>>>>>
>>>
>>
>> _______________________________________________
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
