Implement new Cairo + RSVG SVG backend [DISCL-379] #69
Conversation
rdumusc
force-pushed
the
svg
branch
4 times, most recently
from
59f3d1e
to
77cd3c5
Compare
|
|
||
| mutable QMutex _threadMapMutex; | ||
| typedef std::unique_ptr<SVG> SVGPtr; | ||
| mutable std::map<Qt::HANDLE, SVGPtr> _perThreadSVG; |
There was a problem hiding this comment.
you could use boost::thread_specific_ptr or QThreadStorage for per-thread objects
There was a problem hiding this comment.
Interesting point, but there is a catch here. Apparently QThreadStorage destructor does not deallocate objects, they are instead deleted when the thread that created them exits. Since the calling threads are from the global QThreadPool, in our case the resources would be "leaked" until the application exits. boost::thread_specific_ptr has the same behaviour, and is meant to be used with boost::thread instead of QThread. The reason invoked for this is that it may not be safe to deallocate objects allocated by a different thread. I am not sure if this may be a concern in this case, I copied this implementation from the PDFTiler where we were doing the same.
In any case this multi-threading is quite problematic because allocating a new RSVG context for a ~80MB file takes in the order of ~5s, but then subsequent render calls are faster because they are fully parallel. Using a single RSVG context, the initial impact is lower, but then the render call have to be serialized because RSVG is not thread-safe, which can even slow down the entire QThreadPool. I am not sure what is the optimal solution here.
No description provided.