[scribus] Scribus on 'modern' machines

[John Beardmore]

Craig Ringer wrote:

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

Yes -  I suppose I was thinking of things like image processing, where a 
larch chunk of CPU use has relatively well defined interface to the 
calling code, and there will probably be other things that usefully be 
done while the processing is undertaken.

It would be nice to address the general tardiness of the user interface 
though.  Maybe QT4 will bring some benefits there ?


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

OK.


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

OK.


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

If there's one thing that bugs me about scribus, and it's bugged me 
about Pagemaker and InDesign too, is that editing text in a text box is 
so slow that sometimes it's hard to see what you've typed or selected.

I suspect that in some sense the developers see the 'righteous' answer 
as to use the story editor, but then you can't see how the layout is 
shaping up.  Generally I have a preference for editing direct in the 
text box -  at least it's WYSIWYG.  Personally I'd be happy to dispense 
with the story editor editor altogether, though that may mean that I'm 
missing some tricks.


> [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.]

OK.


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

OK -  Thanks for a very full answer !


Cheers, J/.
-- 
John Beardmore, MSc EDM (Open), B.A. Chem (Oxon), CMIOSH, AIEMA, MEI
Managing Director, T4 Sustainability Limited. http://www.T4sLtd.co.uk/
Carbon Trust Consultant: Energy Audit, Carbon Footprint, Design Advice
Energy Efficiency Accreditation Scheme, (EEAS), Registered Assessor
Phone: 0845 4561332   Mobile: 07785 563116   Skype: t4sustainability