[scribus] Scribus on 'modern' machines
craig at postnewspapers.com.au
Sat May 3 18:44:56 CEST 2008
John Beardmore wrote:
> Craig Ringer wrote:
>> Scribus is single threaded,
> In the long term though, is this because the algorithms can't be
> parallelised, or because that's the way things have evolved ?
A bit of both, and a large dose of "it's way easier to get it right if
you do it in a single thread".
There are definitely areas where using multiple threads would be useful.
Many of them are *not* so much to permit the use of multiple cores for
computation as to permit better UI responsiveness. However, using
multiple threads in situations where the threads must coordinate in
non-trivial ways gets incredibly complicated in a hurry, and may not be
There are lots of tricks Scribus and other programs can use (some of
which Scribus does use) to hide the fact that the program can only do
one thing at once. For example, it can delay work and do it in small
chunks, in between processing user input. This can be surprisingly
complex, though, and may sometimes perform significantly worse than
doing it all in one go. Scribus can also periodically explicitly check
for user input during long-running batch operations - but if you want to
act on user input, not just do things like UI redraws and progress bar
updates, then this too gets very complicated in a hurry.
You may notice that the common element here is "get[s] very complicated
in a hurry". Any sort of non-trivial parallel operation is *hard* to get
right, especially with the rather primitive tools available in C++ and
most other languages. Qt4 helps a little bit, but its facilities were
not around when Scribus was initially written and they are very far from
a complete solution to the complexity anyway.
If Scribus was able to use multiple threads, it could reserve one thread
for the interactive user interface widgets. Theoretically things like
complex text reflow, canvas redraws, image processing, etc could be done
in other threads. In practice, though, synchronizing everything
correctly can be so complex that you have to think carefully about
whether it's worth doing. The easy synchronization methods leave you
with multiple threads, but with only one thread actually doing useful
work at any one time, so you're not gaining anything. If you don't use
such strictly limited synchronization you open yourself to the risk of
weird errors and deadlocks caused by an overlooked interaction between
If you let the user keep on doing things while the program is busy
working on a big task, you similarly create complexity. If a user can
continue working on one document while another is being prepped for
printing, for example, you have to make sure they can do nothing that
modifies the state of the document being prepped for printing.
I'm sure there are a few areas where Scribus _could_ benefit from
muli-threaded parallelism, though.
PDF export comes to mind. PDF has a nice structure where many PDF
objects are largely independent, with only relatively few contact points
between different structures. Scribus could almost certainly export
multiple pages at the same time using different threads. It'd have to
have a synchronized resource manager for xref updates and actual disk
write-out, and would need to do some work to handle shared images,
fonts, and other resources, but it should be possible. It could also use
separate threads for the processing big fonts and images without holding
up the rest of the page export.
This would, however, require a total rewrite of PDF export, and possibly
significant amounts of work elsewhere in the code. It'd be a huge job,
and wouldn't be a huge win if all it did was parallel export. As it
happens PDF export can be improved in other ways (processing images in
small chunks without loading the whole thing into RAM, for example) but
those improvements can be made without rewriting the whole thing.
Mostly, though, there's not much Scribus could gain from multi-threading
without a ground up rewrite. Even then, it'd be hugely complex to gain
much except in a few big batch operations.
[BTW: I mention PDF export partly because I've been idly wondering about
adding support for multithreaded PDF writing in PoDoFo if a C++0x
compiler is available, so I've been thinking about how thread-friendly
> Mind you - I can imagine that in a cross platform development
> environment, keeping things single threaded is one thing less to have go
The cross-platform aspect doesn't seem to be too bad so long as you
stick to doing all your user interface in a single thread, stick to one
thread for disk I/O to/from a particular file, etc.
More information about the scribus