Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


Kohei,
Thanks a lot for your patient answer.
I spent a few hours tracking down where was the bottleneck for my performance issues. Fascinating 
browsing of code.
Anyway, it looks like the culprit is the numerous calls to X11's XRenderCompositeTrapezoids in 
vcl/unx/generic/gdi/xrender_peer.hxx.
For some reasons that I ignore, the "selection border for copied cell range" uses a special 
graphical-to-be-rendered object that, at the end of the day, invokes this 
XRenderCompositeTrapezoids method many many times (I guess one call per dash).
A few things to note:
1. I am not sure if the method itself is very slow. Using a for loop around the call in the 
following code https://github.com/ereslibre/x11/blob/master/xrender/xrhello.c I am able to 
basically time a call at 0.16 ms on my current machine. It may be alright for a few calls, but if 
we have to show a few 100s of dashes, it's not surprising sluggishness effects can be seen.
2. If I change ScOverlayDashedBorder::createOverlayObjectPrimitive2DSequence() to return a 
PolygonStrokePrimitive2D instead of a PolyPolygonMarkerPrimitive2D, I get a solid line instead of a 
dashed line, but no performance problem at all.
3. If I just comment out the call to XRenderCompositeTrapezoids in the XRenderPeer, the dashed line 
does not show anymore but pretty much everything else work without any problem, and no performance 
problems at all.
4. When I just "return false;" at the first line of the bool 
X11SalGraphicsImpl::drawFilledTrapezoids( const ::basegfx::B2DTrapezoid* pB2DTraps, int nTrapCount, 
double fTransparency ) implementation, I assume that it triggers a fallback rendering 
implementation. The performance is definitely better, though I can still feel the sluggishness when 
I do very wide (and wild) selection copy (i.e. select a few cells veritcally, press shift space, 
and then Ctrl+C).
No idea what is the code path for the fall back implementation...

#3 and #4 leads me to think that the numerous calls to XRenderCompositeTrapezoids are costly on 
some machines.

FYI I have a ATI Radeon HD 7700/7800 running the RADEON X driver at home, but use a Nvidia NVS 510 
video card with the proprietary nvidia driver at work. I experience the performance issues with 
selected copy both at home and at work, despite the different graphical configuration.

Anyway, I am not sure how the performance could be drastically improved. I feel just running a 
"personally built Libreoffice" on my machine which just replace the PolyPolygonMarkerPrimitive2D 
with a PolygonStrokePrimitive2D in ScOverlayDashedBorder::createOverlayObjectPrimitive2DSequence() 
is a last resort option. Obviously I'd love to get a proper solution in the Libreoffice trunk.

Any comments?

S

Date: Wed, 30 Sep 2015 08:49:22 -0400
From: libreoffice@kohei.us
To: ross_dev@hotmail.com; libreoffice@lists.freedesktop.org
Subject: Re: [Calc] Bad rendering performance of "selected copy" snake/circulation animation



On September 29, 2015 at 12:25 AM Sylvain R <ross_dev@hotmail.com> wrote:


Hi,
Sorry in advance if this is the wrong mailing list, I am basically trying to
find a tiny bit of help to fix a rendering problem I have and hopefully submit
a patch for it, or at least discuss the problem.
I am having some serious rendering performance problems when I perform a copy
of cells, for some time now, which is a problem as I use Libreoffice calc
pretty much every day as part of my job (running Libreoffice
1:5.0.2~rc2-0ubuntu1~trusty2 on Ubuntu 14.04 64bit).
I decided I could try to fix this problem myself as I am familiar with C++.

Excellent!  We appreciate your willingness to dive into the code.

I am basically looking for a pointer as to where is the code that render the
"copy cell circling effect". I am not sure how it is called, but this is what
I am talking about at http://s14.postimg.org/6u32kqdq9

We (at least I) call it selection border for copied cell range.

What I am trying to figure out:- Where is the code in charge of the rendering
of the circulating selecion?- Where is the code that receives/handles the
scrolling?

The state of this border is stored in ScGridWindow, as mpOOSelectionBorder data
member, which itself is an instance of ScOverlayDashedBorder.  All of these are
in the sc module.  You can run git grep for find these guys.

Now, the lower level rendering is done some place else, and you'll likely have
to move between svx (where the Sdr* classes live), basegfx and drawinglayer.
 And eventually the code path will reach in vcl to do the actual rendering.
 This is a high level overview of how drawing objects are rendered.


I am really just looking for pointers (i.e. a class name or two) for where to
start.

Hopefully the above is a good staring point.  If you encounter more specific
questions in some of these drawing layer code, feel free to post more questions.

Thanks!

Kohei

--
Kohei Yoshida, LibreOffice Calc hacker
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
                                          

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.