Quote:
Originally Posted by kovidgoyal
|
I read that as guaranteeing they are reentrant, not threadsafe. Also, loadFromData() seems to be the supposed problem, which might be different from "painting" into threads.
Quote:
|
Coming to your patch, its hard to know if it actually fixes the issue or just changes timing. If we have identified QImage not being thread safe as the culprit, then I would rather remove QImage completely from the render thread if that can be done performantly. I will look at it when I have some time, feel free to experiment further yourself if you want to, I will post here when I start working on it.
|
I agree that it could merely be hiding the problem. But if so, it is doing a good job at it.
I suspect the safest solution is the one you referred to, using the thread to fetch the data from the disk cache but do no Qt ops on it. The cached data would be passed back to re_render() in the GUI via the update_item signal already there. Re_render() would convert & size the image, store it in the CoverCache, then trigger the item repaint(). This should take approximately the same number of CPU cycles as doing it in the render thread, and the queue system already there would prevent the UI from being blocked for noticable periods. As a side benefit, I think CoverCache would no longer need locking because it would run only on the GUI thread. I will look at this approach if/when I get the energy.