[Digikam-devel] extragear/graphics/digikam

[Marcel Wiesweg]

> 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 (:=)))
>
> Gilles
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel