Issue 105065

Summary: Fontwork Stalls Computer
Product: Writer Reporter: munguanaweza <munguanaweza>
Component: formattingAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@sw <issues>
Severity: Trivial    
Priority: P3 CC: Armin.Le.Grand, cno, issues, michael.ruess, thb
Version: OOo 3.1.1Keywords: needmoreinfo, oooqa
Target Milestone: ---   
Hardware: PC   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 99999    
Description Flags
bugdoc none

Description munguanaweza 2009-09-14 18:26:33 UTC
When I set fontwork onto a page, moving the fontwork will cause the computer to
chug.  The %cpu readout in top is 56% soffice.bin and Xorg 42% until the problem
resolves itself.  Then readouts are about 1-2% for both.  Also, once the
fontwork is set, if I try to scroll the page past the fontwork it will also
cause the computer to chug.

I asked on the mailing list for my linux distro (OpenSuse 11.1) if anyone else
had this problem and found that they did.  They were able to resolve it by going
to tools>options>view>deselect antialiasing.  That has caused the problem I
described above to stop.  However, I was asked on the list to submit this as a
bug to Open Office, which you can read that I have done.
Comment 1 eric.savary 2009-09-14 19:31:01 UTC
Please check if this happens also in Draw.
Check that you can reproduce it in the OOo version of our site in case you use a
distro version.
Attach a sample document.

@AW: any performance issue in this area?
Comment 2 Armin Le Grand 2009-09-15 10:22:38 UTC
AW->ES: Already fixed (and double to) #i100851#, so i guess an older version was
used. There is also information missing:
Old or new Fontork? 
Only on Linux? 
Is it better when setting LineWidth to 0?

Comment 3 michael.ruess 2009-09-15 16:22:29 UTC
Maybe this is a special problem of the XServer or of the 64it build of OOo. I
will have a look on my 64bit ubuntu later.
Comment 4 munguanaweza 2009-09-15 16:35:41 UTC
I received an email last evening shortly before I left on a business trip 
asking me to download and install the src tarball OOo in place of the OpenSuse 
OOo rpm in order to try and narrow down where the problem lies.  I won't be 
able to do that for a week-and-a-half until I get back from my business trip.

I had the problem both on my 64 bit system laptop and on my 32 bit system 
desktop both with OOo 3.1.1 installled with Opensuse.  I tried it on elive 
which has OOo 2.6 installed and didn't have the problem of computer chugging.  
But the fontwork didn't render correctly, they were much thinner than in 
3.1.1.  I also checked in 2.6 to see if I could disable antialiasing, and there 
was no selection box for this in tools>options>view.
Comment 5 michael.ruess 2009-09-15 19:43:27 UTC
I checked with 32bit on Suse and 64bit OOo 3.1.1 on ubuntu but I could not
detect a problem like the described. Highest OOo cpu peak was 12%. I think it is
a problem of the OOo build provided by Novell or something with the XServer.
Please use the OOo from our download page.
Comment 6 michael.ruess 2009-09-15 19:43:44 UTC
Comment 7 thb 2009-09-24 12:25:17 UTC
Sorry, but this apparently is not an issue between ooo-build and vanilla OOo.
Tried 3.1.1 and the very latest dev300-m59 snapshot builds from, and it even got worse for dev300.

I've tried both debian stable + opensuse 11.1 (both 64 bit), on the original
nvidia closed-source drivers; inserting a 'favorite 11' fontwork & typing like
two lines of text (around 70 characters), and zooming/resizing/moving the
fontwork shape is barely usable.
Comment 8 thb 2009-09-24 12:26:13 UTC
confirming problem.
Comment 9 michael.ruess 2009-09-24 13:20:19 UTC
OK, it refers to certain types of Fontwork objects.
The favorite 11 fontwork is such a case. Easy to see when you try to move such
an object around.
Maybe this is related to issue 58291. Happens not only in Writer, could also see
this in Draw.
Comment 10 Armin Le Grand 2009-09-24 15:04:00 UTC
AW: This is not very concrete. Could someone on Linux (THB?) please do some more
concrete tests?

-> Is it Linux only at all?
-> favorite 11 uses 3D, thus (as long as no HW accelerated 3D is usable) this
cannot be changed currently
-> Is it with objects like favorite 11 which use 3D?
-> is it more with objects using fat lines?
-> The movement itself changed to FullDrag (which of course has to do more than
the old stuff; the object has to be rendererd all the time). For fast dragging,
switch it of in draw/impress using the options toolbar. Does this help?
Comment 11 Regina Henschel 2009-09-24 15:46:34 UTC
-> Is it Linux only at all?
I work on WinXp. It does not "stall" but is slow. Drag-Drop one the fontwork
object needs 2-3 seconds on my fast computer. You see the preview or dotted line
after ½-1 second, and the whole object has moved after additional 1-2 seconds.

-> Is it with objects like favorite 11 which use 3D?
When I switch off extrusion, it moves nearly as fast as other objects (like a
group of characters converted to curve) but still more bumpy than other objects.

-> is it more with objects using fat lines?
It makes no difference whether you set border line to invisible, hairline or
others. It makes no difference which font weight you use. But gradient filling
is noticeable slower than color filling and color filling is smoother than
gradient filling.

-> For fast dragging, switch it of in draw/impress using the options toolbar.
Does this help?
In 3D form, in case of color filling without FullDrag is noticeable better, in
case of gradient filling it is as bad as with FullDrag.
Comment 12 thb 2009-09-24 19:32:08 UTC
A few more data points:

> Is it Linux only at all?
Yes and no - tried a Mac m57, scrolling past such a fontwork object is almost
ok; everything else is quite slow, but quicker than on Linux

> favorite 11 uses 3D, thus (as long as no HW accelerated 3D is usable) this
cannot be changed currently
Yes, the 2D/3D difference is marked - though 3D without AA is snappy on all
platforms I tried.

The problem really is impaired by the fact that the whole UI blocks;
additionally on Linux, the old problem of queued events gets on top of it, i.e.
when resizing the object, instead of rendering the first and the last position,
quite some intermediate states are rendered (which of course is a separate bug).
Comment 13 wolframgarten 2009-10-13 08:04:16 UTC
I have checked this with the attached bugdoc on XP with m1 and it has gotten
much worse since the 3.1.1. in Draw. I will request this as a showstopper as
this makes it hard to work with Fontwork.
Even changing the cursor when moving over a selected fontwork takes more time.
Comment 14 wolframgarten 2009-10-13 08:07:26 UTC
Created attachment 65329 [details]
Comment 15 Armin Le Grand 2009-10-13 10:37:26 UTC
AW: I have made some progress with #i105323# in CWS aw078, also experimented for
#i105655# and the problem is known. The problem is that the needed changes are
mixed in aw078 and much too risky and broad for 3.2 showstopper handling. Thus,
i am not sure how much we could take over from those already found solutions for
3.2. HTH.
Comment 16 Armin Le Grand 2009-10-20 15:28:56 UTC
AW: Trying to move the most needed changes from CWS aw078 over. Chagesets include:

changeset:   263023:3cd4ed8338e1
user:        Armin Le Grand <Armin.Le.Grand@Sun.COM>
date:        Thu Sep 24 12:38:31 2009 +0200
summary:     #i105323# shadow shall not be set at 3D model objects for the
generation of visualisation objects

changeset:   263027:8f0a46f77e56
user:        Armin Le Grand <Armin.Le.Grand@Sun.COM>
date:        Tue Sep 29 15:35:35 2009 +0200
summary:     #i105323# speedup of 3D handling mostly for CustomShapes; HitTest
and interactions optimized

changeset:   263029:cc9395d9e911
user:        Armin Le Grand <Armin.Le.Grand@Sun.COM>
date:        Wed Oct 07 14:25:40 2009 +0200
summary:     #i105323# added FastPath for 3D scene HitTest for 3d CustomShapes
by re-using the buffered last render result from the ScenePrimitive2D

I hope i can integrate these, trying...
Comment 17 Armin Le Grand 2009-10-20 16:43:28 UTC
AW: Integration has worked better than expected; FontWorks (and other 3D) is
really speeded up now. Checked in, done.
Comment 18 cno 2009-10-20 20:08:12 UTC
@aw: before you handle this issue over to someone else:
Was good to notice all the progress in i105655. Maybe good for a nice follow up
in GullFoss about the GSL...
And super that this i105065 takes advantage as well!
Thanks a lot, Cor
Comment 19 Armin Le Grand 2009-10-22 10:54:59 UTC
AW: Checked in CWS build, works well.
AW->WG: Please verify in CWS ooo32gsl02
Comment 20 wolframgarten 2009-10-26 14:25:01 UTC
Verified in CWS.
Comment 21 cno 2009-10-27 21:36:07 UTC
Is known in which build this cws will be integrated ?
Comment 22 wolframgarten 2009-10-28 08:47:41 UTC
At least it will make its way into 3.2 final. Before, Ithink it will be the
OOO320_m4 version.
Comment 23 wolframgarten 2009-11-03 20:28:33 UTC
*** Issue 106561 has been marked as a duplicate of this issue. ***
Comment 24 johnny_weissmueller 2009-11-06 16:53:01 UTC
Hi all,

I could observe the same CPU load problem under Windows XP with Presentations
which contain numerous bitmaps and some lines, which I added as an explanation. 

CPU load of a core2duo 9300 is 50 %, and goes back to 10 % with a lot of
performance gain if I deactivate antaliasing. However, then the lines appear