[Qt-interest] QAbstractItemModel data supplied by a different thread.

[Justus Best]

Hi,
> As for an example, I believe the Qt Mandelbrot example uses threads for rendering sections of the scene.
thanks, I will have a look into it.

> I would use a thread pool, populated with some number of threads proportional to the number of processors you have. For the scaling, create a work request class that will hold the parameters necessary to define the image to scale [...]
Also thanks for that, but the principles of multithread programming 
where clear to me allready. My problem was more about the lazy 
population of QT itemViews, maybe I could have pointed this out a little 
bit more clear.
My idea was to add a slot to my model which receives the signal that a 
new image is ready plus the row of the image. Then store the image into 
the QPixmapCache with a key based on the row and emit the models 
dataChanged signal with an index determined from the row returned by the 
thread.
With this in mind I wasn't sure which thread machanism to use. Is it 
better to call QtConcurrent::run for every image or is it possible, if I 
create a list with images, to use the Qt::Concurrend::mapped function ? 
I'm not 100% sure what the mapped function does, if it will only return 
the list of strings I have passed as they are not getting changed in the 
function or if a new List with the results of the functions (QPair of 
QPixmap and int) is created.
Or do I have to call  QtConcurrent::mappedReduced and emit a signal in 
the Reduce funtion ?
Or is it better for my case to use a more low level thread approch and 
implement a processing class which inherits from QRunnable.

Really would like a tutorial on that one, but thanks in advance, I guess 
I understood a lot more just by writing this mail and marshalling my 
thoughts.

Justus

Am 27.07.2010 16:57, schrieb Brad Howes:
> On Jul 27, 2010, at 7:45 AM, Justus Best wrote:
>
>    
>> I trying to implement a fancy looking kinetic scrollable ListView. The
>> fancy looking and the kinetic scrolling I could solve by my self, but
>> the images I'm displaying have to be scaled first which leads to
>> performance problems if I do the scaling in the data function. I hoped
>> that using some functions from QtConcurrent could solve my problem, but
>> I can't exactly find out how to bring this together.
>> What would be the "right" solution to get the job done, should I display
>> placeholder images at first and call
>> QtConcurrent::run(someScalingFunction...) install a QFutureWatcher on
>> the result and emmit the dataChanged-Signal every time a new Pixmap is
>> ready ? Or is there another solution.
>> I'm open for any suggestions or some examples where I can look up how to
>> do this right.
>>      
>
> I would use a thread pool, populated with some number of threads proportional to the number of processors you have. For the scaling, create a work request class that will hold the parameters necessary to define the image to scale, the scaling to perform, and whatever values are necessary to communicate to the widget where the image lives in its view. Create a consumer/producer queue for the thread pool that will hold the work requests. For all images in the view widget, create a work request with appropriate parameters and add to the queue. The worker threads are all waiting to consume from the queue. When a worker thread gets a work request object, it performs the necessary scaling, and when done, emits a thread-safe signal to the view widget with the appropriate parameters telling the view widget what image was scaled as well as the scaled image itself.
>
> The QtConcurrent library may have some of the above for you to use; I don't know since I have not used it yet.
>
> As for an example, I believe the Qt Mandelbrot example uses threads for rendering sections of the scene.
>
> Brad
>
>