[scribus] Scribus on 'modern' machines

[Craig Ringer]

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 
worth it.

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 
threads.

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 
PDF is.]

> Mind you -  I can imagine that in a cross platform development 
> environment, keeping things single threaded is one thing less to have go 
> wrong.

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.

--
Craig Ringer