[Digikam-devel] extragear/graphics/digikam

[Gilles Caulier]

Le Mercredi 14 Décembre 2005 20:48, Marcel Wiesweg a écrit :
> > I have identified 2 methods to do it :
> >
> > 1/ Using a KIOSlave (prefered) : This is the most powerfull method but
> > not trivail solution because data will be shared between digikam and
> > kioslave using a simpe bytes array. An image in digikam is not a simple
> > pixels array but a complex class instance (DImg) including pixels,
> > metada, ICC profiles, properties, etc...
>
> KIO has some mechanisms, but it might be a real pain to serialize such a
> complex class. IMO serializing is bad and multi-threaded programming is
> fun :-)
>
> > 2/ Using a children thread using QThread. This is complex to do because
> > file descriptors are shared between GUI thread and loader thead. image
> > loader methods must be tradesafe too (this is not the case actually).
> > This will complex and long to finalize. Nota : this method is used by
> > Kimdaba, Gwenview and showimg to load images using QImage. but digiKam do
> > not use QImage to load/save image by a dedicaced API named DImg...
>
> Some thoughts on this.
>
> - the more public the Dimg objects will be and the more threads, the more
> locking must be installed.
> Easiest case is some Dimg objects private to IE and one loading thread
> private to IE. In this case, only the communication with the thread must be
> locked, see below for an example.
>
> If there are other threads accessing the objects, there must probably be a
> mutex per object. With a mutex per object, you can (with care for pixmap
> conversion of course) extend that to a heavily multithreaded environment,
> stuff like locking for reading and writing, but we probably don't need
> that.
>
> - There is no fundamental difference between DImg and QImage for threads.
> In the end, there is a chunk of data.
>
> - File loaders (and thus libjpeg, libpng etc.) must be reentrant. If they
> are not, the one simple solution is one mutex per loader. Note that in Qt4,
> the relevant classes all are reentrant, so they have solved this. (in the
> world of multi-core CPUs, I think non-reentrant libs are anachronisms)
>
>
> PreloadedThread::checkLoaded(DImg &img, Object *notify) {
> 	QMutexLocker lock(mutex);
> 	if (!img.isLoaded())
> 		todo.push_back(new LoadingTask(img, notify))
> }
>
> PreloadThread::run() {
> 	while(running) {
> 		Task *task=0;
> 		{
> 			QMutexLocker lock(mutex);
> 			if (!todo.isEmpty())
> 			task=todo.pop();
> 		}
> 		if (task) {
> 			task.Execute(); //loads image, sends QCustomEvents to GUI thread
> 			delete task();
> 		}
> 	}
> }
>
> IE::nextImage() {
> 	...
> 	preloadImage(nextImage, this);
> 	// No lock on this object - knows not too touch this object,
> 	// somehow stores or knows which object(s) are being preloaded
> }
>
> > Please fix me if something is wrong. Any viewpoints welcome (:=)))
> >

Ah marcel, you is a thread guru. I'm not one (:=))) Thanks for these 
informations. Perhaps you can help me to implement a Thread Image Loader for 
DImg ?
-- 
Gilles