On Thu, 2003-08-14 at 03:02, Thomas Ahlstrom wrote: > Hi > > I'm running Scribus 1.0.1 on RH8.1 with latest QT-version. Scribus > seems terribly slow when working with text flowing through typically > 25 A4 pages 2 columns. That includes both loading and -- when > eventually loaded -- editing the text. Waiting 10-15 seconds between > every edit move. >
> > Any comments? > > /Thomas Certainly, I run the same - with the exception of compiling my own Qt 3.1.2 from source. It is my experience with RH Qt packages that their extensive patching of Qt has a lot subtle adverse affects on Scribus stability. With 7.2 and 7.3 I reported many crashes and issues to Franz which he could not repeat. In hindsight, I can attribute this to the extensive patches RH applied to Qt and KDE. I find the KDE-Redhat packages on sourceforge - much better for running Scribus. Slow text handling is in part, owing to the XML based format. A trade off - open, extensible and very resistant to corruption. Since the I started working with Scribus from 0.3.7 and throughout all of the bleeding edge cvs versions, I think I have lost *at most* a half dozen documents to corruption/crashes and IIRC three were related to a specific bug which was quickly quashed by Franz. I have probably created a few hundred Scribus docs over time. You should also be aware, as Franz has really made an honest effort to really make Scribus useful in professional DTP settings, I have continually pushed Scribus harder and harder in testing. My yardstick is the DTP apps I use and support professionally. Example, with 1.0, I got Scribus for the first time to export a print ready PDF of an EPS map which has almost 60,000 curves and segments. This croaks even new P4 machines when opened in Illustrator or InDesign. When printed, it is identical to the print created in Acrobat 6. Earlier this week, I got Scribus 1.0.1 to generate a 150 MB 2400 dpi PDF with lots of TIFFS, imported PDF's from Indesign and smaller EPS files. Ask any long time Pagemaker or Quark user about doc corruption. For some this is constant problem, which is solved only through very careful OS setup, system maintenance and extensive network testing. Fixing this stuff is part of my day job. When I started this took me many months of testing and reading to avoid this for clients. Indesign in this regard is better, but still not perfect. One other observation I have more recently noticed which affects Scribus is image quality, flicker and redraw speed are partly a video card / driver quality issue and the design of Xfree86. Honestly, some of the Xfree drivers, while stable are not as speedy as Win2k or XP on the same hardware. Plus, keep in mind Xfree86 runs in userland, so it shares equal billing with any other process. On Win32, start a processor monitor and then start dragging windows around. The CPU spikes immediately to 100% and stays there until you stop. Do the same with Xfree86 and there is a bit of a lag in CPU usage, nor can display refresh hog the CPU. With the 2.6 kernel, this should be much better. A lot of attention was spent on the kernel scheduler and I/O. Other examples: On the Win2k box which I test built versions of Scribus, The screen display was overall sharper and less flickery than the Linux box I have at home - and they have the same monitors with the same refresh rate. It simply has a superior video card and very stable updated Win2k drivers. Even with the beta ports of Qt and KDE on Win2k with the slower I/O from way POSIX sockets are handled , the display is excellent and redraw is snappy both with Scribus and KDE3. You can see the screen shots on the kde cygwin page on line with the docs. One of the comments from the Slashdot story was crappy screen shots. I have a test machine (luckily lent by one of my clients) which is the only machine I now use for screen shots. Why? It has a very high end dual display Matrox card chosen for DTP work with 120 DPI screen resolution. A while back, I compiled earlier Qt2 versions of Scribus under Solaris 8. The font display was excellent with Type 1 fonts - on a par with a good Win2k or Mac screen. Why? Solaris' Xwin has display postscript technology from Adobe. And screen redraws were *very* quick. The difference is the basic Type 1 rasterizer in Xfree86 comes from older IBM technology. Only with the latest Freetype/Xft2 tricks can Xfree86 even approach that kind of font display quality you can get with the Adobe display code. >Why so long texts you wonder? Answer: Books. Of course one can put >chapters in separate files and so on in the future, but the slow >handling of long texts worries me a little bit. While Scribus is not yet optimized for long documents, it can handle them. I have a 390 page Scribus doc which I use for testing. When there is page handling changes in the code, I open this up to test navigation speed etc. Switching from the first to the last is usually fairly quick. As another test, I imported the whole text of the Scribus on line docs in one linked doc - 60-70 pages. It handles it fine, a bit slow, but usable. Performance Fixes: If you are not adverse to compiling from source, get Qt 3.2.0 and make a parallel install, so you do not affect KDE and other apps. Then set QTDIR environment variable to /usr/local/qt32 or such. Then compile Scribus and Qt 3.2 - hopefully against gcc 3.2 or better gcc 3.3 with march=set properly. Scribus has a lot of floating point math code which optimized much better with gcc 3.2+ and the correct -march= set properly. This is especially helpful for P3+ and Athlon chips. A lot of work was put into gcc 3.2+ to optimize the C and C++ compiler for newer CPUs like PIII and P4. Even the first 3.2 beta from Qt had some redraw speedups vs. 3.1.2, but it was very unstable with Scribus. The main issue comes from auto flowing text. So, once the text is flowed in, then break the text chains in to logical sections. Then lock the text frames in place so they do not move. Both options speed redraws quite a bit. Other DTP applications suffer similarly. Switching pages in Pagemaker and Quark are not exactly speedy depending on your display settings in the doc. Moreover, Quark has never been known to display graphics at any thing more than low res proxy settings. Pagemaker is defaulted to low res as well, but can be over ridden. Only with the latest hardware can you tolerate the high res settings. I would also note Quark, PM and ID have the option to "Greek" text under certain sizes - just to speed redraws. I would also note Indesign 1.0 and 1.5 were heavily criticized for being performance pigs - they were. I read a story about the program manager for the release of 2.0 having a banner on his wall which said "Performance, Performance, Performance". Use a faster window manager. I run KDE 3.1.2 with Mosfet's Liquid 90% of the time, but when I am doing extensive work in Scribus at home I run the minimalist Blackbox. It allows Scribus to start and redraws are quicker. Other apps like Mozilla and Evolution seem to run much quicker. Plus, the minimalist decor avoids helps to avoid visual distractions. Lastly, disable all animation tricks in your display settings. On the DTP machines I support, they all have boring gray desktops with all the eye candy completely disabled - no wallpaper, no animation, nothing whether Macs or Win boxes. Fast Hardware helps DTP apps in particular. Go back a few years to running Pagemaker on low end Pentiums - that was painful at times. While, Scribus is not as hardware intensive as other DTP apps, faster hardware helps any type of DTP related application. The test box, purpose built for DTP - actually a modified HP engineering workstation, I mentioned is really pleasant to use Scribus on. It runs Scribus fast enough to actually just open and start typing. I would note running Idesign or Illustrator 10 on anything less than a PIII takes ages to load and is not fast in redrawing. Illy 10 burns up 48-60 MB of memory on launch with no doc open, Scribus uses about 16-18 on RH 8/9. Quark 5 and Indesign use more. >From a DTP viewpoint, my experience handling chapters in separate files is probably good practice. Once the whole document is done you can import the other pages and export PDF or print as one. For graphic intense docs, it is often better to handle them in even smaller page groups. One of my clients creates a magazine in Pagemaker and Indesign. They create separate files for every two pages in a reader's spread (facing pages) layout. When complete, then they are actually output as imposition ready PDF's as separate one page files. This makes edits and changes actually quite a bit simpler and faster. I know this is a bit long, but I wanted to give those on the list (hard core Scribus users) some perspective with other DTP apps and other factors which affect this - it is just not the code. Scribus performs very well in other areas like file saves, PDF generation and file importing. The scripter plug-in works very quickly considering Python is an interpreted language. I find the scripts run as quickly as the scripting engine in Pagemaker or Illustrator - and it is far easier to use. For first time users this can be a surprise with any DTP app and maybe a disappointment on first use. No, it is not ideal, but not hopeless for the future. Regards, Peter ________________________________________________________________________
