Please attach a test document.
Are you using version from ubuntu distribution or official version?

Created attachment 68636 [details]
test file exhibiting slow chart scrolls. Pls see "Grafer" tab

We are currently using the Ubuntu distributed versions on most computers. I have
however installed the latest official version downloaded from your site on one
of our most used laptop types (Dell Vostro 1015, I-Core2Duo 2.2Mhz, 2Gb Ram).

The results are the same as previously described.

Reproducible on ubuntu 9.10, DEV300m75. Slow scrolling, high CPU usage. 
[dell latitude d820, T2500 @ 2.00GHz, 2,5 GB RAM,  nVidia Quadro NVS
110M/GeForce Go 7300]

The PC mentioned in my earlier post running ooo300m15 on Ubuntu 9.04 that was
more or less ok has now been upgraded to Ubuntu 10.04 and ooo320m12 (ubuntu
version).
This PC now exhibits the same problem to full extent rendering calc virtually
useless on larger files with charts.

I am getting a lot of grief from my users in regards to this issue (I convinced
them to go over to Ooo). Pls let me know if there is any solution in the pipe.

I know this is not a solution but perhaps something like not updating the charts
until the scroll action is completed could be implemented? IE on scrollbar
movement: no chart redraw until mouse button is released, and no chart redraw
until mouse scroll-wheel has stopped for x ms. I think this could perhaps help
alleviate the problem.

@aw, is there a way to speed up the rendering of metafiles containing polygons
with many many points?

AW->IHA: Polygon output now goes pretty direct to the sub-system, e.g. on WIN32
to GDI+, so this is very system-dependent. For fat lines (that's the most time
consuming part) we added some faster and more direct trapezoid decomposer which
is needed for AAed rendering. HDU can tell in which version this is used now, i
am currently not sure. Setting HDU on cc.
Just did a fast profiling on WIN32, most time is spent inside the GDI+ methods
(in the OS).

IHA->AW: Does that mean - no the rendering cannot be fastened?
If so please consider whether a multithreaded asynchron preparation of the
metafiles is possible.
If you think that nothing can be done here please close the issue as cannot fix.
If you think there are chances for enhancement please assign the issue to that
one who can do them. The chart itself has nothing to do with the metafile
rendering, so I am the wrong owner.
Thanks!

AW->IHA: You asked a question and i answered it. I saw no mention to take over
and OTOH we will need HDU's answer, too.

>If so please consider whether a multithreaded asynchron preparation of the
>metafiles is possible.

The Metafile is already only once decomposed to primitives and those are already
buffered. Thus, at repaint, that data goes pretty direct to the system-level
rendering (VCL), as i already described. Since VCL is not multi-thread safe
itself, multithreading is no option unless VCL is changed to work with that (an
old known problem with solarmutex).

>If you think there are chances for enhancement please assign the issue to that
>one who can do them. The chart itself has nothing to do with the metafile
>rendering, so I am the wrong owner.

It would also be possible inside the chart to reduce the data points in a useful
manner (as AFAIK is done already for some chart types). Maybe, our big
competitor is doing something like this? So there are of course also
optimization methods within the chart itself from my POV.

AW->IHA: Please add information how many points those fat lined polygons exist of.
AW->HDU: Please add information when the new trapezoid decomposer is in action.

To not make anyone feel bad, I'll just keep the task for now. Usually it goes to
the one who is to add information, but who cares...

@iha,@aw: please test with CWS vcl111: there the very expensive (because uncached) call to check for self 
intersections can be avoided because the new intersection-tolerant tesselator is used

AW: Thanks HDU. When will vcl111 be integrated?
AW: Also a good read: #i98907# shows what is already done and how much speed
improvements are already done (see measurements at the end). Together with
#i111021# which is mostly for Linux/Solaris the 3.3 should solve the problem.

AW: Investigated the idea of nixvitae to break the repaint when scrolling again.
I already tried to do something like that once. Problem is that VCL is not
multithreaded and there is no way to break the current paint when a change
happened. I tried to add a 'break'-flag for all paint and to stop AFAP when set,
but then method to react on inputs (AnyInput()) is not fine granular enough to
implement something like this.

I also compared locally fat line painting outside chart: Created an impress doc
with 3 lines a 5580 points. Speed is comparable with chart display. I also again
ensured that just GDI+ is called as direct as possible. It is...

Hi Everyone,

I suffer with this behavior since a long ago. Both on linux, x86-64 (OpenSuSE,
Go-OO derived and now Libò and vanilla linux x86-64 to help testing 3.3) and
Windows.

I just retest OOo 3.3, rc8, vanilla, linux x86-64 with my calc-with-graph file
and this issue's file and these are the results:

- with my multisheet Calc file (that I immediately attach) I must wait about 10
s to view one of last two graph sheets, xorg process gain 98% cpu for some
seconds both in viewing graph sheet or scrolling it (each time), then cpu come
back down and OOo is pretty usable;

- with this issue Calc file I saw the two graphs after about one minute but OOo
still remains occupied (cpu level at about 100%) and I must close (not kill) it.

I think this behavior must be faced up. We have to deal with it to get more
professional use of the very important OOo (and derived) part that is Calc with
its functions and capabilities.

Isn't it?

Carlo

Created attachment 75356 [details]
Multisheet Calc file with last two sheet with graphs suffering high cpu rendering in both viewing and scrolling

Two last considerations:

- I just attach my ods file saved with vanilla OOo 3.3rc8 whose size is 736.9
kByte, but the 7z version is 158.8 kByte (only!!!); this surprised me because
ods is also a compressed (zipped) file but I did't expect a similar difference
in sizes. 7zipping the first issue file with the same system yields two similar
sizes: ods file size is 1.1 MByte, 7zipped one is 926.7 kByte. What do you think
about?

- I think objects (graphs, non bitmap graphics file format, ...) cacheing (with
the bitmap rendered version) is a good first way, but I ask myself because first
render time is so high (too high!!!) and so what is wrong in some architectural
choices. I think demanding to OS graph part the object rendering is a correct
way but with this performance there is clearly something that escape and slip
out to us. Is there someone (e.g. like someone of the
Blender/FreeCad/Brl-Cad/Pov-Ray/... teams) that could help us first fixing and
then re-engineering this subsystem?

Carlo

Some test on a Mac to your information:
I'm using MacOS X 10.6 on a nearly five years old 1,83 GHz Intel Core Duo MacBook pro 
Openig the document and holding "scroll down"-arrow with the mouse 
OOo 3.2.1 scrolls tolerable nice (19 sec. for all full scroll of the document)
OOo 3.3.rc8 is really slower (30 sec. or all full scroll of the document)
LibreOffice 3.3.rc1 has most problems with that (35 sec. or all full scroll of the document)

AW: Thanks for the new inputs. Please also read the old findings above;
slowdowns are the cost for AntiAliasing improvements. Those do not come for free
unfortunately but need more rendering time - not in OOo, but in the
system-dependent graphic systems, e.g. on WIN GDI+ which AAed is simply slower
than not-AAed. If You do not need AAed output, You may switch it off in
tools/options/view and see old speed of non-AAed versions of OOo return, but
pixeled. You cannot have the money and the choccolate :-(

For Unix/Linux OTOH there is XRender and it's ability to only render trapezoids
or triangles if AA is wanted. This means that for those systems a
triangulation/trapezoidation is needed which is in place and pretty fast already.

We are constantly working on this (various tasks already), but AAed graphic will
never get the speed of non-AAed with the same amount of graphic data to be
rendered. I still think for big charts a reduction of data depending on the
resolution to visualize would be an option, too.

AW->uwealtmann: For the difference between OOo 3.2.1 (19 sec.) and OOo 3.3.rc8
(30 sec.) i have no idea right now; i will take a look what has changed in the
Mac version. Since there were no changes in Drawinglayer, maybe the rendering
layer for MacOS has changed somehow here...

AW->PL: Unfortunately i have no Mac to evaluate this. Cold You please take a
look and evaluate the difference between OOo 3.2.1 and OOo 3.3, maybe on Mac fat
AAed lines are not yet painted optimal. Those lines go directly from primitives
to VCL using system rendering (see desc10).

.

I just tried 2 reproduce on debian squeeze with kde4 and opengl (debian OO
3.2.1-11).

Generating the graphs takes about 2 sec with AA on by dual core 3GHz.

Tried to export to xls and view with Excel (under wine) but the indirect
addressing used doesn't seem to work in Excel. Another bug?

Unfortunately I can not compare now. But would not be surprised is MS caches the
bitmap after rendering.

Ferry

AW->ftoth: Thanks for checking this out. It would be nice if you (or anyone else
listening) could get the Excel comparison to work, or do at least some charting
there with the same amount of data and size.

Bitmap caching is not really an option here; OOo intends to run on small
systems, too, and with the sizes of bitmaps we are talking here about we try to
avoid things like that. Let a Sheet have some of this charts (not even complex)
and memory explodes. We already had some iterations of tasks from people whom
the footprint is too big, and they have valid reasons.

I am still wondering about system draw performance; as stated above (and checked
in debugging) the geometry (fat lines here) is pretty directly dumped to GDI+
(in Windoes case), so it's not the architecture of the OOo graphic subsystem in
general. A problem still is that there is no way with VCL today to check if the
view has changed again during paint and break it cleanly. Multithreading support
could also help, but currently will not work with VCL, too.

Hi Everyone,

I was thinking  over, reflecting on, the various OS modules to which you (we)
are demanding the sheet rendering (anti aliasing and so on)...

Are we so sure that the current chosen modules (GDI+, XRender, Drawinglayer) are
the one the OSes now (!) are powered to do these kind of tasks???

May be that the chosen modules are obsolete (at all or at least for these kind
of tasks) and maintained by the various OSes only for retro-compatibility?

I ask myself this question because I have in mind that in the 3D graphics we
frequently deal with 30 or 40 fps (frames per second!!!) and here we are on the
contrary speaking of 1 frame in 20 or more seconds and so 1/20 fps that is 0,05
fps...!!!

Is this caused only for the pour 2D performance with respect to the richest 3D
one or are the chosen modules obsolete as supposed by me?

Do you think there are something that sound wrong? And this is not the sound
card nor pulse audio! ;-)

Carlo

... may be the correct ones are:
DirectX, OpenGL, OpenGL

instead of
GDI+, XRender, Drawinglayer

?

What do you think about?

AW: I really wish it would be soo easy :-(

DirectX and OpenGL are 3D renderers, which:
(a) cannot paint offscreen
(b) do not AA at all basically
(c) do not paint PolyPolygons, nor fat lines

(a) means that You only can paint to screen directly and accept a return of
flickering screen contents. Currently the repaint goes into a offscreen surface
and gets copied to the front to avoid flickering, thus only renderers which can
render to offscreen surfaces are usable.
Second possibility is switching two contents (e.g. of a window). Problem here is
that the whole OOo window IS a system window, the UI elements around the paint
surface (toolbars, side panes, ...) are no system windows, but VCL (virtual)
windows which would be overpainted. In both cases, the whole VCL and apps need
to be adapted/rewritten to be flipped completely/to not paint in regions of VCL
windows.

(a) also means You have no way for printing; the resolutions would be so huge in
print output preparation that you would need another method of preparation for
that (2nd renderer). This also needs renderers which can work offscreen, if
bitmap preparation for printing is needed (e.g. the case for transparent parts
in objects).

(b) means that you would need some e.g. 4x4 oversampling; besides the video mem
needed (remember OOo is also for small devices and older machines) You never get
the full 256-step-AAed view 2D renderers can do. A quality loss.

(c) means that You would have to generate the filled polygon geometry for the
fat lines and triangulate them. This means (esp. in the examples) megabytes of
data You need to buffer if you want fast repaints. Also triangulation (despite
we have it) is not cheap at all.

Believe me, currently what we use is pretty much the best you can use. Without a
complete rewrite (or a very huge adaption) of OOo with those concepts in mind,
this cannot be done (unfortunately). You may try it out, it's open source.

The better way would be to make VCL thread-save and being able to stop the
current paint when the user scrolls (kinda lazy-repainting of complicated
regions). This is also a huge task (people tried to make VCL reentrant and
thrad-safe for some years already), but it's more doable than using 3D renderers.

Sorry for the bad news, but it's more complicated than a first look may show...

Thank you aw, I believe and trust in you! ;-)

CL: Some small corrections. While AW is right with his conclusion, DirectX and
OpenGL

(a) can paint offscreen
(b) support AA
(c) could paint PolyPolygons and fat lines using Shaders

But all this comes at a cost and printing is the main reason why we
still need a fast and quality software renderer.

For printing it would be so much easer if there was an accepted standard cross
platform vector format like PDF on the Macs.

One short term solution for Windows platforms only would be to replace gdi+ with
direct draw (*) which is the new Windows 7 only rendering API for vector
graphics. GDI+ is dead slow so at least for Windows 7 users this should ease the
pain with not a lot of work.

Has any one compared the rendering speed on mac? I'm curious how the Quartz
rendering compares to XRender and GDI+

(*) direct draw is not the 2d rendering api available in old Direct X versions,
its a new interface introduced by microsoft for Windows 7

I notice that movement of charts is slower in OOo3.3 than in OOo3.2. This is
independent of the settings for antialiasing. It is not impossible to move the
chart, but it makes no fun to wait two seconds till the graphic is on its new
place. Refresh of the screen while scrolling is affected too. A smooth scrolling
with the slider is not possible in the new OOo3.3 version.

"alg" committed SVN revision 1480935 into trunk:
i110384 added better fat line rendering where possible

ALG: Added better FatLine drawing where we have something already in VCL, this makes things much better already. Still no smooth scrolling, but a refresh of (at my local conditions) 4s compared to 25s before, not that bad. More is possible, but will need system-dependent renderers.

adjusted target to version that will contain the fix