[Scribus] speed problem once more

[unknown]

hi all!

i have a strange problem using scribus and am curious if any one will know
what may by going on. first i have to say that i'm completely new to linux
(switched from windows few weeks ago). i was quite enthusiastic about
possibility of using free dtp program and it's great that there is such a
project and is developing. unfortunatelly i soon noticed that scribus
performance on my system puts into question a possibility of using it.

i've searched the archive a bit and found other people reporting speed
issues but in this case the behaviour is i think quite different. when i
put some text frames on the page it starts to work very slowly, i.e.
display is very slow (and it is only on pages with the text). it doesn't
seem to be connected with any particular order of joined frames (as sb
described here) nor with any particular feature. the slowness just grows
proportionally to the amount of text and to complexity of formating. it
also seems independent on fonts used. what is most curious is that pdf
exported displays just as slowly (in adobe reader 7, but also on windows)
or even slower. the frames appear slugishly one by one and sometimes even
cause adobe to stop responding for a while. similar pdf made earlier with
pagemaker displays without problems virtually in real time.

i have madrake 10.1 official, athlon 64, 1gb ram
i tried the version provided by mandrake ass well as 1.2.2cvs rpm for mdk
from the repository linked on scribus website. i also by some miracle
managed to compile from sources and to compile ghostscript 8.50 and gave
the path to it in sribus, everything according to the instructions on
scribus site and it's exactly the same.

any suggestions?

regards
k

[unknown]

Hello,

just to make shure, there is no hardware/ configuration issue:

What is the output of the following command (as root):

hdparm -t /dev/hda3

I get:
/dev/hda3:
Timing buffered disk reads: 162 MB in 3.04 seconds = 53.25 MB/sec
(60 GB Harddisk, 7200 rpm)

(Instead of hda3 type the name of the partition, where you store your files.
To find out the correct name, type
df -h
)

Are you shure, more than 10% of your diskspace is free?

What gives:
free
as result?

I get:
total used free shared buffers cached
Mem: 514404 267360 247044 0 3072 120756
-/+ buffers/cache: 143532 370872
Swap: 530136 56 530080

In my case I have 370872 Bytes free memory (this is the number, that
counts.)

If you work with a large amount of text, you should edit it using the
integrated
text editor.
There is a known speed issue if you edit text in the WYSIWYG mode, it
will be improved
a little bit in the 1.3 version of scribus.

Regards:

ufechner

Post by unknown
hi all!
i have a strange problem using scribus and am curious if any one will know
what may by going on. first i have to say that i'm completely new to linux
(switched from windows few weeks ago). i was quite enthusiastic about
possibility of using free dtp program and it's great that there is such a
project and is developing. unfortunatelly i soon noticed that scribus
performance on my system puts into question a possibility of using it.
i've searched the archive a bit and found other people reporting speed
issues but in this case the behaviour is i think quite different. when i
put some text frames on the page it starts to work very slowly, i.e.
display is very slow (and it is only on pages with the text). it doesn't
seem to be connected with any particular order of joined frames (as sb
described here) nor with any particular feature. the slowness just grows
proportionally to the amount of text and to complexity of formating. it
also seems independent on fonts used. what is most curious is that pdf
exported displays just as slowly (in adobe reader 7, but also on windows)
or even slower. the frames appear slugishly one by one and sometimes even
cause adobe to stop responding for a while. similar pdf made earlier with
pagemaker displays without problems virtually in real time.
i have madrake 10.1 official, athlon 64, 1gb ram
i tried the version provided by mandrake ass well as 1.2.2cvs rpm for mdk
from the repository linked on scribus website. i also by some miracle
managed to compile from sources and to compile ghostscript 8.50 and gave
the path to it in sribus, everything according to the instructions on
scribus site and it's exactly the same.
any suggestions?
regards
k
_______________________________________________
Scribus mailing list
Scribus at nashi.altmuehlnet.de
http://nashi.altmuehlnet.de/mailman/listinfo/scribus

[unknown]

Post by unknown
Hello,

hello!

Post by unknown
hdparm -t /dev/hda3
Timing buffered disk reads: 162 MB in 3.04 seconds = 53.25 MB/sec
(60 GB Harddisk, 7200 rpm)

/dev/sda8:
Timing buffered disk reads: 154 MB in 3.01 seconds = 51.14 MB/sec
BLKFLSBUF failed: Operation not supported
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Operation not supported

heh?

Post by unknown
Are you shure, more than 10% of your diskspace is free?

yep

Post by unknown
free
as result?

total used free shared buffers cached
Mem: 1035964 1029452 6512 0 152352 497672
-/+ buffers/cache: 379428 656536
Swap: 2546260 160 2546100

Post by unknown
If you work with a large amount of text, you should edit it using the
integrated
text editor.
There is a known speed issue if you edit text in the WYSIWYG mode, it
will be improved
a little bit in the 1.3 version of scribus.

yes, i've noticed. but it's also just displaying that is slow. i was even
begining to think that it's not that bad and i can live with it, but than
after few minutes back to pagemaker... it's uncomparable.

and why it takes several seconds for pdfs (just text and picture) to display
in adobe...? while similar ones show instantly. i don't see how it could be
connected to hardware.

anyway, thank you for your suggestions!

ps. i also tried fedora yesterday and it's the same. please, tell me that it
is not just how this program works...

regards
kuba

[unknown]

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me that it
is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed. You say
PageMaker in Windows is fast on your same machine? and Scribus is slow
in screen writes?

Frank

[unknown]

Post by unknown

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me that
it is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed. You say
PageMaker in Windows is fast on your same machine? and Scribus is slow
in screen writes?

Perhaps it would help to run top, k system guard or whatever your choice
of system monitor is to see what process(es) are possibly eating up
system resources (ie memory, cpu cycles and etc...).

Just a suggestion.

Regards

Marvin

[unknown]

Post by unknown

Post by unknown

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me
that it is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed. You say
PageMaker in Windows is fast on your same machine? and Scribus is slow
in screen writes?

Perhaps it would help to run top, k system guard or whatever your choice
of system monitor is to see what process(es) are possibly eating up
system resources (ie memory, cpu cycles and etc...).

i run kde sys guard. to be sincere i'm not sure how to take usefull info from
it. in table of processes "user %" for scribus rises to about 90% when i'm
moving pages with lot of text. i don't know if it tells anything...

regards
k

[unknown]

i am begining to think we have a troll on our hands

Post by unknown

Post by unknown

Post by unknown

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me
that it is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed. You say
PageMaker in Windows is fast on your same machine? and Scribus is slow
in screen writes?

Perhaps it would help to run top, k system guard or whatever your choice
of system monitor is to see what process(es) are possibly eating up
system resources (ie memory, cpu cycles and etc...).

i run kde sys guard. to be sincere i'm not sure how to take usefull info from
it. in table of processes "user %" for scribus rises to about 90% when i'm
moving pages with lot of text. i don't know if it tells anything...
regards
k
_______________________________________________
Scribus mailing list
Scribus at nashi.altmuehlnet.de
http://nashi.altmuehlnet.de/mailman/listinfo/scribus

[unknown]

Post by unknown
i am begining to think we have a troll on our hands

I think that's a bit premature.

He's not baiting anybody. One can generally smell trolls a mile off, and
I think we're largely free of them here. It's not necessarily useful to
belabour a point that's already well recognised and is being worked on,
but it hardly makes the poster worthy of being tagged a "troll."

I think we probably do need a FAQ entry on performance with lots of text
though.

[unknown]

Post by unknown

Post by unknown

Post by unknown

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me
that it is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed. You say
PageMaker in Windows is fast on your same machine? and Scribus is slow
in screen writes?

Perhaps it would help to run top, k system guard or whatever your choice
of system monitor is to see what process(es) are possibly eating up
system resources (ie memory, cpu cycles and etc...).

i run kde sys guard. to be sincere i'm not sure how to take usefull info
from it. in table of processes "user %" for scribus rises to about 90% when
i'm moving pages with lot of text. i don't know if it tells anything...

I think its been said before. Yes, we know there are some speed issues
sometimes, especially with various situations with regards to text.

At this point there is no need for any particular reports on this. It will not
be fixed in 1.2.x. We have plans for various rewrites in 1.3.x that should
alleviate these issues.

regards
Craig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20050421/e42e8739/attachment.pgp

[unknown]

Post by unknown
I think its been said before. Yes, we know there are some speed issues
sometimes, especially with various situations with regards to text.
At this point there is no need for any particular reports on this. It will
not be fixed in 1.2.x. We have plans for various rewrites in 1.3.x that
should alleviate these issues.

ok, sorry, i finish the topic.

[unknown]

Strip the scribus binary and things will speed up some. The
trade off is no debugging info in the event of a problem.
FWIW, Pagemake is stripped (For other reasons).

Regards

Marvin

[unknown]

Post by unknown
Strip the scribus binary and things will speed up some. The
trade off is no debugging info in the event of a problem.

That's interesting. My understanding was that stripping binaries didn't
gain you much, if anything. Some quick research suggests that some
extremely CPU intensive apps gain as much as 4% when stripped. That's
about 1/10 of a second in a two-second operation, which I doubt would
generally even be noticed.

Until a few days ago, non-debug builds were stripped by default during
build. That is still true in 1.2.2cvs, but 1.3 no longer strips during
build (this was causing problems on MacOS/X). If you want to install
stripped binaries, use "make install-strip" instead of "make install".

If you're using 1.3, please build with --enable-debug and don't strip
the binary. Othewise the debugging information is useless.

Post by unknown
FWIW, Pagemake is stripped (For other reasons).

Yes, I imagine they want to make it as hard as possible to reverse
engineer and delve around in the internals of. It also makes it harder
to tamper with the binary to work around copy protection etc, though it
seems people always do it anyway.

--
Craig Ringer

[unknown]

Post by unknown

Post by unknown
Strip the scribus binary and things will speed up some. The
trade off is no debugging info in the event of a problem.

That's interesting. My understanding was that stripping binaries didn't
gain you much, if anything. Some quick research suggests that some
extremely CPU intensive apps gain as much as 4% when stripped. That's
about 1/10 of a second in a two-second operation, which I doubt would
generally even be noticed.

The main focus of my work revolves around firmware. It has been my experience
that in single operations the gain is not noticeable to humans. However,
operations that are reiterated hundreds or thousands of times to complete a
task benefit because the "task" is seen by the user as a singular event when
in fact, "under the hood" it is the sum total of multiple operations. Now,
I've not really looked at the code that comprises Scribus. But, in an
application as large as Scribus is, there is a high likelyhood that this
paradigm applies. But, then again - I've not looked at the code.

Regards

Marvin

[unknown]

Post by unknown

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me that it
is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed.

Well, depending on what you're doing - some workloads seem very snappy,
others people have performance issues with. It can sometimes use a lot
of memory and/or spend a lot of time redrawing, or can be very
lightweight and fast.

Post by unknown
You say PageMaker in Windows is fast on your same machine?
and Scribus is slow in screen writes?
From the versions of PageMaker I remember using, I can believe that. Its

performance was IMO one of its main attractions, and it was quite
practical to write in it as well as use it for layout (somewhat like
FrameMaker in that regard, really). I remember it being snappy on a
66MHz 601 with 32MB RAM.

On the flip side, the versions I used achieved that partly by displaying
terrible "screen previews" of graphics, or just greyed out placeholders,
and doing rather quick'n'dirty font rendering.

[unknown]

Post by unknown

Post by unknown
Scribus is robust, fast, even with 1000 fonts installed.

Well, depending on what you're doing - some workloads seem very snappy,
others people have performance issues with. It can sometimes use a lot
of memory and/or spend a lot of time redrawing, or can be very
lightweight and fast.

well, i can understand that some compex graphical works may make it slow, but
come on, if with DTP program i cannot make relatively comfortably a standard
newspaper page, for me something is wrong.

regards
k

[unknown]

hello, sorry for delay in answering.

Post by unknown

Post by unknown
ps. i also tried fedora yesterday and it's the same. please, tell me that
it is not just how this program works...

Scribus is robust, fast, even with 1000 fonts installed. You say
PageMaker in Windows is fast on your same machine? and Scribus is slow
in screen writes?

exactly. i run them on the same machine. and it's not some small difference.
in PM when i move a page etc. everything happens virtually in real time. in
scribus after every single move, redisplaying of the page takes 1-2 seconds
(forget about scrolling).

i also haven't noticed any major problems with performance of other apps on my
linux.

k

[unknown]

Hi,
Sorry for late answer.

Post by unknown
i've searched the archive a bit and found other people reporting speed
issues but in this case the behaviour is i think quite different. when i
put some text frames on the page it starts to work very slowly, i.e.
display is very slow (and it is only on pages with the text). it doesn't
seem to be connected with any particular order of joined frames (as sb

Yes, it's the text frames that make it slow.
First is not to use automatic hypehnation which makes it only worse because
every single syllable is generated as a own object, so set the hyphens
manually.
What I didn't test yet is wether rendering a justified text is slower that
rendering a aligned text. I'm sure there's some difference.
If that is still too slow for you, i have a hack to render only the
selected page, but i don't think you're using cvs1.3 and you should anyways.

ciao, tom

[unknown]

Post by unknown
If that is still too slow for you, i have a hack to render only the
selected page, but i don't think you're using cvs1.3 and you should anyways.

Er... probably not for production work, since it uses an interim file
format, it may occasionally have partially completed work in it, etc.

You can use 1.3 if you like the bleeding edge, but if it breaks, that's
the risk you take.

[unknown]

Post by unknown

Post by unknown
If that is still too slow for you, i have a hack to render only the
selected page, but i don't think you're using cvs1.3 and you should anyways.

Er... probably not for production work, since it uses an interim file
format, it may occasionally have partially completed work in it, etc.

sorry, meant "shouldn't".

ciao, tom

[unknown]

Post by unknown
Hi,
Sorry for late answer.

Post by unknown
i've searched the archive a bit and found other people reporting speed
issues but in this case the behaviour is i think quite different. when i
put some text frames on the page it starts to work very slowly, i.e.
display is very slow (and it is only on pages with the text). it doesn't
seem to be connected with any particular order of joined frames (as sb

Yes, it's the text frames that make it slow.
First is not to use automatic hypehnation which makes it only worse because
every single syllable is generated as a own object, so set the hyphens
manually.

you are joking, yes? ;)

Post by unknown
What I didn't test yet is wether rendering a justified text is slower that
rendering a aligned text. I'm sure there's some difference.

yes, it seems to be some, as well as regarding to auto-hyp on/off, but it
certainly isn't any qualitative difference.

Post by unknown
If that is still too slow for you, i have a hack to render only the
selected page, but i don't think you're using cvs1.3 and you should anyways.

no, i use 1.2.2 cvs

well, thanks for suggestions!
regards
k

[unknown]

Hi kuba!

Does the speed improve if you use a different font?

/Andreas