msClipPolygonRect() / msClipPolylineRect()

[Sean Gillies]

My understanding is that since 2.0.12 GD clips automatically.  Is
MapServer's clipping needed anymore?

Sean

On Mar 24, 2005, at 10:57 AM, Stephen Woodbridge wrote:

> Frank,
>
> Excellent! Performance has been an issue discussed on the list in
> resent
> history, any chance of getting this fix back ported to a dot release of
> 4.4.x
>
> I think that we should defer to the shapefile spec on bounds being set
> correctly. It is possible to have "bad" shapefiles so so some sanity
> checks should be in the code to trap bogus or out of bounds values and
> then die with some useful message about which file was bad. I would
> then
> add a bounds check to the verify or check shape utility to report and
> fix things.
>
> I would rather assume that my data is good and get the extra rendering
> speed and if I have bogus data then running lots of files through the
> checker is the price I have to pay.
>
> -Steve
>
> Frank Warmerdam wrote:
>> Folks,
>>
>> As part of an optimization project, funded by the Department of
>> Fisheries and Oceans I am digging through a few things.  I found
>> that in my test rendering something 15% of my time was spent in
>> msClipPolygonRect() as part of normal rendering.
>>
>> A quick review highlighted that many of the features being put
>> through clipping were completely within the clip rectangle, so alot
>> of work was being done to accomplish no change.  I have modified
>> msClipPolygonRect() and msClipPolylineRect() in 4.5 CVS to return
>> immediately if they determine that the bounds of the shape are
>> completely within the clip rectangle.
>>
>> In my case this cut the clipping time by about 50%.
>>
>> My only concern with this change is whether there is any risk of
>> shapeObj bounds not being correct.  Does anyone know of circumstances
>> when the bound might not be in sync with the actual contents of the
>> shape?
>>
>> I have applied the same change to msClipPolygonRect() though I
>> don't use it much in my test case.
>>
>> I suspect that there may be futher opportunities for optimization on
>> this function. For instance, it doesn't seem like there is any point
>> in computing intersects for line segments where both end points are
>> within the search rect.
>>
>> Best regards,
>> --
>> ---------------------------------------
>> +--------------------------------------
>> I set the clouds in motion - turn up   | Frank Warmerdam,
>> warmerdam at pobox.com
>> light and sound - activate the windows | http://pobox.com/~warmerdam
>> and watch the world go round - Rush    | Geospatial Programmer for
>> Rent
>>
>