Polylines can disappear completely using AGG renderer

[jbirch]

At small scales, some lines can dissappear using the AGG renderer.

See the attached images, showing two different layers (polyline layer in orange, polygon layer in green) of Nanaimo parcels. At this full extent, the AGG renderer does not display the polylines, though the GD renderer does.

In this case, these lines were set as device space, 1 point.

[jbirch]

Lines display using GD renderer

[jbirch]

Lines don't display using the AGG renderer

[tomfukushima]

Hi Jason, Can you attach the layer definition for that layer that has the disappearing lines? I would like to see how it is styled so that we could try to reproduce. Thanks Tom

[tomfukushima]

Oh, nevermind, I see it now... device space, 1 point.

[jbirch]

I've also just noticed that this occurs with the polylines that are created for a polygon border, not just for polyline data sources.

[tonyfang]

In AGGRenderer::DrawScreenPolyline, the outline renderer is used to draw the polylines if the line weight is thin (<= 3 pixels). For Parcels.sdf (from the Redding data set), it is 1 pixel. The outline renderer seems to be dropping vertices when they are overlapping -- thus the lines don't all get rendered when the polyline data is dense.

I removed the outline renderer code in AGGRenderer::DrawScreenPolyline, forcing it to stroke the lines as polygons -- this is code path taken when the lines are thick (> 3 pixels). After doing so, all the dense lines are rendered, yielding the expected results.

There is a performance penalty. With my debug MG server, using the outline renderer, it takes 2.39 sec to render (albeit with missing lines). Using the stroke as polygon code, it takes 3.407 sec to render.

The user can get around this rendering slowness by using standard optimization techniques such as generalization and/or scale ranges. So this slowness will probably not affect our end users in general.

​http://trac.osgeo.org/mapguide/changeset/3454

[zspitzer]

AGG with 2.0 was already a big performance penalty over 1.2 with GD, a 30% slow down is pretty damn painful, especially when it comes to tiled maps which exacerbates the problem as that's roughly 30% times 20 for the average full screen display. ouch...

would it be possible to add a trace warning for this maybe with the new logging api?

[tonyfang]

I just want to clarify the numbers from above. The times quoted refer to the time spent to stylize the layer on the debug MG server. So if you factor in the time to transfer the data from the server to the client (which should be the same for both), other server processing, and client processing, then the performance penalty isn't quite as significant.

As a comparison, I just tried running the same test with GD Renderer, it took ~1.7 sec to stylize the layer on the debug MG server when rendering the same data. And the DWF Viewer takes ~4.6 sec.

Can you provide more details about your trace warning? When exactly did you want it to occur and what do you want it to say?

[zspitzer]

probably getting into a little bug spam here, but mapguide rendering is a bit of a black box performance wise. I see tiles which render in 200s or 60s whilst the next tiles render in 1s of 10s. It would be nice to be able to pin point what the bottle necks are.