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: libreoff...@kohei.us > To: ross_...@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_...@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
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
