Rendering is significantly slowed down by complex clip setups - which can be caught like this:
diff --git a/vcl/headless/svpgdi.cxx b/vcl/headless/svpgdi.cxx
index 6f993db..aa43951 100644
@@ -304,7 +304,10 @@ bool SvpSalGraphics::setClipRegion( const vcl::Region& i_rClip )
m_bClipSetup = true;
+ SAL_DEBUG("Complex clipping regions pushed " << aRectangles);
m_bClipSetup = false;
To reproduce run:
./tilebench `pwd` /opt/libreoffice/testfiles/CP41vsAOO401/groupshape.rtf
preferably under callgrind under master - and you'll see the issue.
We -try- hard to defer setting up an alpha clipping mask - since that is usually huge and also horribly expensive =)
Stupidly we do this even for rendering rectangles which -should- be easy to do; and (it seems) the biggest chunk of our time is spent filling those masks.
We should either:
a) stop creating un-necessarily complex clipping setups: I can't see why we would need anything more complex than a simple rectangle ~ever really =) quite possibly the code is just being obtuse and we can fix it higher up.
b) handle rectangle & line rendering better.
I attach a prototype patch here [ that incidentally screws up all the rectangle rendering - as you can see if you load groupshape.rtf in 'gtktiledrender' ;-] which needs some more thought as to why it breaks ~everything I guess ;-)
Quite possibly we need to do gradient rendering for the outline / border of the document - or somesuch in BitmapDevice itself - only profiling will tell.
Created attachment 107444 [details]
prototype (non-working) rect rendering patch ...
I got impatient and killed most of the silliness here - its now ~fast to create and set monochrome 1bit clip-rects; at least - reasonably fast for now.
So - perhaps worth closing this.