Apache OpenOffice (AOO) Bugzilla – Issue 105065
Fontwork Stalls Computer
Last modified: 2017-05-20 11:42:05 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.
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?
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? HTH ATM
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.
Hi, 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.
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.
Closed.
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 download.openoffice.org, 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.
confirming problem.
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.
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?
-> 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.
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).
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.
Created attachment 65329 [details] bugdoc
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.
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...
AW: Integration has worked better than expected; FontWorks (and other 3D) is really speeded up now. Checked in, done.
@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
AW: Checked in CWS build, works well. AW->WG: Please verify in CWS ooo32gsl02
Verified in CWS.
Is known in which build this cws will be integrated ? Thanks,
At least it will make its way into 3.2 final. Before, Ithink it will be the OOO320_m4 version.
*** Issue 106561 has been marked as a duplicate of this issue. ***
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 terrible.... John