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