Apache OpenOffice (AOO) Bugzilla – Issue 7629
Flicker in rendering gradient filled polygons (patch)
Last modified: 2003-01-14 13:25:38 UTC
The attached patch fixes the flicker for me; at the cost of a new visual.
Created attachment 2787 [details] the patch.
Thanks
Accepted as a performance problem
Okay, slowly but surely getting to the reasons why this was implemented the way it is. The problem with using clip regions or the attached fix is, that depending on OS, graphic hardware, zoom level and object complexity, you will wait quite some seconds before _anything_ of the gradient filled object is drawn. The old approach, on the other hand, was at least "doing something" (although that something was really ugly). So, the way it is, I don't think it's wise to take the fix right away. Currently trying to figure out if the painting of the gradient itself (which is the bottleneck for the problem described above) can be sped up.
Reverted to painting the gradient with a set clip region. That gives immediate visual feedback to the user, but the painting occurs only within the polygon area. Sadly, that revealed a bug in our clip region implementation, which I was not able to fix up to now (actually, I don't know if it is fixable without major overhaul).
Not convinced totally by the explanation. Ultimately, the slow part of rendering this, I imagine - has to be rendering the gradient polygon - which is rendered off screen and then blitted onto the display [ AFAIR ], so ... the umpteen polygon renders of the gradient [ vs. the most likely faster polygon render ] will happen off-screen [ AFAIR ].
The status quo is painting the up to 255 coloured polygons for the gradient, clipped to the bounding rectangle of the polygon-to-be-filled. Your fix moves all painting offscreen, which can lead to a several second long lag during repaint. My try was to set the fill polygon as a clip region, and render the coloured polygons into that clip. Gives immediate visual feedback, but is buggy for several special cases of polygons: try this at the known place: { Rectangle aBoundRect( rPolyPoly.GetBoundRect() ); Push( PUSH_CLIPREGION ); IntersectClipRegion( rPolyPoly ); DrawGradient( aBoundRect, aGradient ); Pop(); } Just for laughs, I attached a document containing a polygon that looks kinda funny with that fix...
Most interesting; my co-worker; federico@ximian.com is re-implementing the gpc intersector using libart due to licensing issue; and I'm sure would be most interested in this.
Okay, okay, although not completely convinced, we'll do it as you proposed: painting completely within a VDev now. What finally made me reverting to this solution was the fact that we cannot guarantee pixel-by-pixel match with any home-brewn clipping or scanline-conversion, _if_ we subsequently paint the border of a polygon with Windows/X11/whatever system routines. Find the fix in vcl/source/gdi/outdev4.cxx rev. 1.12
Reopened, has to be verified.
Marc, please verify and close if okay.
fixed
closed