I just tried in OOO310m7, which I still have running,
Also slow there, but not so slow as in OOO310m9

I see the same behavior in German OOo3.1RC1. If you use the old drag modus
(uncheck 'Objekt mit Attributen ändern')then dragging is quick.

I can see the same problem with the textbox or with text in a classical rectangle.

same on linux (but I can only confirm for fontwork o 3D objects).

performance is better, if antialiasing is not enabled.

Testet on a Intel Mac witz OS X 10.5.x and m8 from SUN

The Speed is a little bit slower, but ok

But if I move a fontwork with the mouse. It's going loosed. Maybe that's the
same Problem.

Add myself to CC

Have tested in 3.0.0 on another XP installation.
Is fine there > regr..

(thanks to regina for explaining me that the "Modify Object with attributes"
button is available on/for the Options toolbar in Draw)

I see that disabeling ant-aliassing makes significantly more difference than
disabeling Modify object with attributes.

Mac Intel, 3.1.rc1 from Sun: Text edit is OK but moving the Object is remarkably slowly in updating the 
display. Switching antialiasing off speeds up things, but display is still too slow updating.
3.0.1 isn't faster, it's only seems so because its simply not displaying a preview when moving the 
Fontwork.
btw: NeoOffice 3.0 (which is based on 3.0.1 code and hasn't implemented antialiasing) doesn't show this 
problem at all.

I can confirm this bug on Mandriva 2008.1 and 2009.0 32bit, ooo310m9. With
antialiasing on, performance is extremly poor, practically working with fontwork
is impossible. Problem is in all modules (writer, draw, calc,...).

The delay when dragging is reproducible, yes. And like it was said before, the
anti-aliasing seems to be the reason. But I cannot subscribe that working with
fontwork is impossible. At least not with my two test-machines here. Reassigned.

On my machine it is slower but not so slow that I could not work with it.

@aw: Please have a look.

Hi,

My findings, to compare with yours:
- fontwork is selected,
- F2 to edit text > appr. 2.5 seconds
- Home, Shift-End > fast
- Start typing > first letters to appear in appr. 1 second
- Escape, when new text is more than just a few letters > more than one second
- Change focus to other application, Change focus back > more than one second
- Ctrl-W to close/Save document > dlg available and text on controls about 0.5
to 1 second

For me, this is really bad user experience.

 >> IMO we should turn off anti-aliassing by default (which is a pity), or
automatically if someone starts working with Fontwork etc. (which probably is
complicated or tricky)
 >> In any case a big remark in the release notes.

AW: Anti-Aliasing (AA) and FullDrag of course don't come with no cost, but also
both bring huge advantages. AA was the most voted issue ever, we put a lot of
work in implementing and thoroughly looked at each system to get the necessary
speed to make it the new default for OOo 3.1. The default will not be changed,
nearly everyone loves this feature.
We also added the possibility to switch it off for people who do not like/need
it or who's machine maybe do not support AA in hardware, so everyone has it's
alternatives (and we have to keep working code for two alternatives internally
:-(, i'm sure there are developers out there who would have simply removed the
non-aa possibility).

Same goes for FullDrag: It exchanges in the case of FontWork the two vague drag
lines with a full object drag. This is of course more expensive (since it also
will work with re-layouting the object e.g. when resizing), but it greatly
enhances the user's experience and from an ergonomy point of view te first time
ever in OOo history allows a precise interactive placement/modification of objects.
The same here: You can switch it off when You don't like/need it, for the same
costs as mentioned above.

Of course we will try to further enhance rendering speeds in the future and we
take feedback lite this serious, but we tried it on many systems (also on very
weak ones, e.g. a FuSi U800/U1010) and i could not find a situation where it is
'impossible to work' with FontWork; i re-checked right now before answering. Not
even OOo can avoid to use more ressources with better features over the years.

For the 'bad user experience' it can be argumented if it's better to have ugly
edges and no real preview when dragging or the current combination, even when
it's a little bit slower.

Since both features are configurable, initially switched on by purpose and
increasing rendering speed is on the performance list automatically in all
releases, i do not see this as a defect. Switch the features off if You do not
like/need them or Your hardware is not adequate.

I can keep this task as a reminder for rendering performance and as an enhancement.

Hi André,
Thanks for your extensive explanation and sorry if you possibly understood my
comment as if I'm not happy with both features - far from that!
But I also have to do directly with how much people like OOo: users, (potential)
customers.
When they experience this situation, it is important if they can directly solve
the problem, so that not the idea that something is broken settles in their mind!
It takes years to build a reliable image; it can be destroyed in few minutes ...
Cor

AW->HDU: The improvement for Mac is nice, but i just checked the Linux version
(the Platform field should be set), and there it is indeed incredibly slow. I
took my look on a WIN32 plattform where the problem does not exist in that form
(that's why i wrote the comment in that form, guys :-/).
Internally the handling is identical. The difference is AA output methods per se
and maybe VDEV creation under Linux. Please have a thorough look at VDEV
performance on Linux here.

AW->HDU: ...or in short: We should think about #i100888# immediately :-)

Please turn the AA off for wontwork by default. This is a block for older
computers i.e. in schools. Children like the fontwork but this make it unusable
for them. Not all computers are capable of this. A common user can turn it on
but kids can't turn it off.

Another bad news: All vector objects are slowed when Anti-Aliasing is on:
1. Draw some vector object (in writer or draww)
2. In Area Style/Filling choose Gradient a then choose one from gradient. For 
now, object is slowed
3. Choose bigger line width and vector object is more slowed
4. When you add fontwork, you cannot work - soffice.bin + X-server consummed 
90 - 96% CPU
Here http://mandrake.zstenis.org/rpms/test/corrupted_vector.odt is example, 
which consummed 90 - 96% CPU on Mandriva 2008.1, Semprom 3100, 1,2 GB RAM, 
Geforce 7600 GS

@aw: may I understand (comment 16, reg 100885) that a partial fix is rather trivial?

@all: IMO, also reading comments 17 & 18 (and aw's 15, Linux experience), we
should very seriously consider this issue for 3.1

Please retest with >=OOo310_m8 on UNX platforms, as there was a fix for issue 100406.

AW->cornouws: Cannot answer that, HDU has to comment. In general, 100885 is only
a mac optimization.

AW->plastique: There is no easy way to switch off AA for one special operation
(and one system) on the view like FontWork. The AA property is per view granularity.

AW->HDU: We urgently need to profile VDEV creation/handling and PolyPolygon
painting (the trapezoid decomposition) with XRender. There is nothing i can do
from primitive and/or DrawingLayer's POV, it's about VCL performance.

AW: Installing m8 for check..

AW->HDU: Compared ooo310 m7 1nd m9, no real difference. It feels a little bit
faster on m9, but negligible.

@aw: callgrinding shows that most of the cost on UNX is in the methods:
  basegfx::tools::clipPolyggonOnRange()
  basegfx::tools::clipPolygonToParallelAxis()
  basegfx::tools::adaptiveSubdivideByDistance()
  basegfx::tools::getRange()
Since most non-trivial glyph outlines have quite a number of segments any O(n^2) algorithm employed 
in the methods above would be too costly. AFAIK all of them could be implemented as O(n*log n).

The other probably even much more important question is why there is such a tremendous amount of 
polygon drawing operations. In the document sample I'm attaching the resize of the fontwork object 
had almost 100k polygon drawing operations whereas I see only a few visible dozen polygons.

Created attachment 61422 [details]
small reference sample

AW->HDU: All mentioned basegfx polygon operations are quite linear;
clipPolyggonOnRange clips against a rectangle by clipping against the four sides
(clipPolygonToParallelAxis) and only linearly processes the polygon, so in the
methods listed above is no O(n^2) candidate at all.

All of this methods are used in Your imlementation of painting a PolyPolygon
using a XRender extension (X11SalGraphics::drawPolyPolygon), as preparation to
the trapezoid decomposition. There MUST be a cheaper way to paint AAed
polyPolygons on XRender, i hope.

As i already told You, the tremendous amout comes from the fat line geometrical
preperations (see case PRIMITIVE2D_ID_POLYGONSTROKEPRIMITIVE2D in
drawinglayer/source/processor2d/vclpixelprocessor2d.cxx). This does not make the
difference, since exactly the same primitive geometry is feeded to VCL when AA
is switched off.

Even when we change painting fat lines using a VCL-Method to paint the
non-expanded polygon as fat line, internally VCL will do the same line segment
preparations, using the exact same tooling from basegfx. The only difference
would be that the prepared geometry is not buffered in the primitive
decomposition, but preared with each paint in VCL. When there exists a VCL fat
line painting method which directly paints the fat line, we can change this and
support it.

So the key for performance now IS either VDEV preparation or PolyPolygon
painting/preparation for XRender. Both is VCL-specific.

there is an important TODO in the polygon drawing code on UNX:
"move clipping before subdivision when clipPolyonRange learns to handle curves"
@aw: AFAIK this is not yet the case?

AW->HDU: Just a guess: is it necessary to clip the polyPolygon in
X11SalGraphics::drawPolyPolygon at all? An overlapping test is already done at
the start, so - for testing - you may just comment out clipPolygonOnRange and
solveCrossovers to check which is the expensive part. Maybe it's the trapezoid
decomposition ...?

AW->HDU: "move clipping before subdivision when clipPolyonRange learns to handle
curves": Can be done in X11SalGraphics::drawPolyPolygon, but will/should not
change too much except that less edges need to be compared for clipping. In the
standard test case (insert a FontWork on empty page) the clipping will not do
anything anyways since the polygons are completely inside the visible range.

AW->HDU: What maybe expensive for me in X11SalGraphics::drawPolyPolygon is:

        if( aOuterPolygon.areControlPointsUsed() )
            aOuterPolygon = ::basegfx::tools::adaptiveSubdivideByDistance(
aOuterPolygon, 0.125 );

since this subdivides all polygons (which are in discrete coordinates here) to
have deviations less than 0.125 pixels. Maybe a higher value should be tested
here or not giving a bound at all or usage of adaptiveSubdivideByAngle with no
angle bound. That should be sufficient for precision. HTH.

Callgrinding with more debug info showed more hotspots:
basegfx::tools::createAreaGeometry() about 12%

And indeed, most of the time the expensive polygon clipping in basegfx::tools is not needed. The 
problem is that when it is needed it is really needed. Therefore there is an initial test with intersecting 
the polygon range with the viewport range. That simple test has to use the relatively expensive 
getB2DRange(). It is expensive because it tries to be so correct. It would be better if there were really 
cheap methods such as isAllContainedIn(B2DRange&) or isAllOutside(B2DRange&).

Other than that the stlport::priority_queue is unnecessarily expensive because there is no direct way to 
tell it to reserve a large initial vector. So it is resizing all the time. It split of issue 100922 for this.

AW: I experimented with a native OOO310 m9 and AA on Linux in general. My basic
idea was to not use AAed filled PolyPolygon rendering at all, but to paint
non-AAed filled PolyPolygons and their outline as AA-ed hairline.

This works qualitatively well, but is surprisingly not really faster (!). Only
when leaving out paining the AA-ed hairline outlines i get to speed.

This leaves only one result: Painting ANYTHING AA-ed (filled PolyPolygons or
hairlines) on Linux systems using XRender extension is generally one magnitude
slower than non-AAed. It looks like it's not HW_accelerated, but using a
Software-renderer.

So, the question is: What is the most reliable way on Linux to paint AA-ed
geometry to an offscreen raster with HW-Acceleration? I can't believe that
XRender extensions are not using HW-acceleration nowadays...?

>Callgrinding with more debug info showed more hotspots:
>basegfx::tools::createAreaGeometry() about 12%

This is the line geometry generation which is already optimized and using
beziers internally with some error factor.

>...expensive getB2DRange(). It is expensive because it tries to be so correct.

getB2DRange() is also optimized. It does not adaptive subdivide internally as
You might think, but uses Your (and thb's) extreme value search on a bezier
segment to get a very correct result very fast. Only points at the extremes (and
only when the bezier segment is not already in the range) are numerically
calculated, the polygon is in no way processed or changed. Also, the B2DRange is
buffered at the polygon instance and reused.

Another workaround that is IMHO nicer than disabling antialiasing (as suggested in desc 7) is to set the 
line-style to invisible, and renable it when done with editing.

AW: I experimented with adding some old code which i used to play around with
own hairline-AAing. It uses a simple buffer class which allows to add single
transparent, colored pixels and collects them in arrays. On Flush() it gets the
needed part of the destination as Bitmpap, adds the changes and writes them
back. Around eight algorithms for AAing are added.

Believe it or not, that code is faster (!!!) than calling the XRender extension.
It's not extremely fast (Bitmap Op's for each single polygon), but about twice
as fast on my local X-Server as before.

This is incredible, sad and a good proof that all our optimizations on our side
of the problem will have no real effect. The problem is in the XRender
extension, there are some out there which do support AA bad and not in HW.

My test code is not in a usable condition and such a deep change would be too
dangerous for OOo 3.1 release. It would also make OOO3.1 much slower on all
systems where the XRender extension is well supported in HW.

I cannot guess for how many people it will be slow and for how many it will be
fast due to HW-acceleration used by the XRender extension, but i see no
alternative in asking the people for whose it is slow, to switch off AAing and
to look for a better XRender extension for their system.

Measuring the the attached sample document proved that the of AA-enabled drawing and AA-disabled 
drawing has interesting differences. The new DrawingLayer code requests the display of about 100000 
polygons in the AA-enabled case vs. only 4000 polygons in the AA-disabled case. A factor of 25 is quite 
large. AW has a good explanation: AA-disabled case is already adjusted to the output device resolution. 
so it can skip a lot of polygon drawing requests; whereas the AA-enabled case currently requests every 
last detail, so the antialiased subpixels get shaded correctly.

AW: I took the time and experimented a little bit with adaptions to concrete
display resolution. In parallell to Non-AAed necessities (polygons with less
than 2.5 pixels LineWidth need a fallback paint to Hairline) and for other
reasons (performance) i added something similar to the VCL renderer.
In cases of LineWidths between ]0.0 .. 3.0] it is possible to not use the
prepared line geometry, but to paint repeatedly AAed hairlines. This gives a
similar, but cheaper visualisation.
I experimented around and use thee steps now:
]0.0 .. 1.0] -> single hairline
]1.0 .. 2.0] -> 2x2, dynamic line distance
]2.0 .. 3.0] -> cross in a 3x3 (no edge points) , dynamic line distance
This needs 1, 4 or 5 hairline polygon paints, respectively. It is faster, but
with more than 5 hairline paints, it's getting slow again (as said, AA per se is
slow, don't expect wonders here). But it optimizes performance (even for
HW-accelerated systems) and fixes the most common case: The office without zoom
and objects (e.g. FontWork) with thin (but not hair-) lines. Need to check this
change under WIN32 and solaris, too, but maybe a good alternative and a 3.1
candidate. It's also not too risky.

Created attachment 61472 [details]
patch for drawinglayer

AW: Added the geometry reduction for screen display as patch.

@aw: The patch improves the speed considerably. Drawing lines instead of the countless polygons is the 
right approach for target devices, where the difference is hardly visible at all. It reduces the number of 
polygons drawn by a large factor.

I also suggest to use a linewidth instead of drawing a shifted array of hairlines. In my tests replacing the 
shifted hairlines with a wide line makes no noticeable visual difference for linewidths up to e.g. 4. 

>@aw: The patch improves the speed considerably. Drawing lines instead of the
>countless polygons is the right approach for target devices, where the
>difference is hardly visible at all. It reduces the number of polygons
>drawn by a large factor.

Not considerably. As You measured Yourself, a factor of 25 is used for the
non-AAed case. This shows that latest at line widths of 5 (5x5 == 25) this will
paint the same amount of polygons, where the prepared line polygons are smaller.
It goes nearly to the same speed when using up to 4x4.

>I also suggest to use a linewidth instead of drawing a shifted array of
>hairlines. In my tests replacing the shifted hairlines with a wide line
>makes no noticeable visual difference for linewidths up to e.g. 4. 

Very funny, hdu. We discussed about this and You told me several times that
LineWidth is NOT supported through to XRenderExtension, i also checked this
several times. This WOULD be good and the choice for this cases, not only for up
to 4 pixels, but always. IMPLEMENT IT in VCL!
What You suggest (and what You tested) is the SAME line geometry preparation
done in the DrawLine implementation in VCL then used in primitive decomposition.
I already told in desc26 that the only difference is that the geometry is not
buffered when using it in VCL, but being created at each paint...

I agree that the patch is a good idea for 3.1.

> you told me several times that LineWidth is NOT supported through to XRender [code path]

Line width is only supported for xdpi==ydpi devices because that would require support from createAreaGeometry() for asymmetric geometries.

> what you suggest is the SAME line geometry preparation done in the DrawLine implementation
> in VCL then used in primitive decomposition.

If there only was a cheaper method of creating polygons for lines... createAreaGeometry() creates a 
perfect (but polygon-count heavy and thus expensive) geometry while we just need a geometry good-
enough for the target device... something like "emboldening" a line. I know that approach is not perfect 
from a theoretical standpoint but e.g. flattening "wild" curves, then expanding perpendicular to both 
sides and then removing self intersections would be good enough for typical linewidths on a display. 
And it would create only few extra polygons if at all. That is no OOx3.1 material though, maybe I'll have 
a go at it for 3.x. E.g. freetype's FT_Outline_Embolden does it in a similar way and I haven't read many 
complaints about the visual quality.

> If there only was a cheaper method of creating polygons for lines...
>createAreaGeometry() creates a perfect (but polygon-count heavy and thus
>expensive) geometry while we just need a geometry good-enough for the target
>device... something like "emboldening" a line.

createAreaGeometry() is already doing a good job (i told You). Just go to
PolygonStrokePrimitive2D::createLocalDecomposition and set the static bool
bTestByUsingRandomColor to true to visualize the created geometry in a running
office and play around with it...

installationset for review is available on
ftp://qa-upload.services.openoffice.org/aw068/OOo_3.1.0_090409_unxlngi6_install.tar.gz

Hi aw, hdu, *,
Thanks for your good attention for this issue.
I see the review-installation set for Linux, and have the impression - from what
I remember reading last day's - that work being done is (mainly) for that
platform, due to some technical stuf.
Do I understand that correct?

> I see the review-installation set for Linux, and have the impression - from what I remember
> reading last day's - that work being done is (mainly) for that platform, due to some technical
> stuff. Do I understand that correct?

No, the remaining problem in this issue (the huge number of polygons) was independent from 
the platform, so Armin's patch to get the number of polygons down again applies to all 
platforms.

The issues I split off are speedups specific to the UNX port though. AFAIK their solutions are 
not applied in the installation.

Another interesting data point is that on remote X11 displays the performance is limited by the network 
bandwidth! (1.0e+5 polygons -> 1.0e+6 render-trapezoids -> 6.0e+6 render-coordinates -> 24 MB 
raw trapezoid data) On a typical setup for X11 remote it takes more than two seconds to transfer all the 
trapezoid data to the X11 server!

AW->HDU: Except the trapezoid decomposition the same data is used in AA and
non-AA cases, so this is not the basic reason for AA being much slower (except
that the trapezoid decomposition blows up data, maybe ...?). Of course less data
is always good, if possible with keeping quality.

AW: Added change and task to CWS aw070, done.

AW->WG: Please verify. You need the unxlngi6.pro version. Follow the 1st
instruction.

Verified in CWS.

Closed.

Nothing is fixed! I tested on my own build (go-oo) and on official release too 
(both ooo310-m11) in Mandrivalinux 2008.1
Fontwork is allways slow, specially with gradient. When is fontwork on page, 
srcolling is not smooth too (when scrollin to place, where fontwork is, OOO + 
X consume cca 70-85% CPU).
For example: Test fontwork Favorite10 in OOO 3.1 and then same fontwork in OOO 
2.0-3.0.1. It is extremly difference in performance.