Some highlights disappear when zooming in

[Julian_Thoms]

Hi Ben, sorry it’s me again. We noticed that some highlights disappear when zooming in in the latest beta.

I think you know our setup by now - if there’s anything else you need to debug this let me know!

(GPU Render only)

I also noticed that zooming further out and back in makes other icons disappear now.

[Julian_Thoms]

We also noticed that (after applying the new highlights) we saw some still cut off (with others missing)

[Ben]

Hi Julian,

In fact, we cannot recreate this one with the latest beta171. Can you share some of your code? Or you can enable the logs as following and send me the log file:

ThinkGeoDebugger.LogLevel = ThinkGeoLogLevel.Message;
ThinkGeoDebugger.LogType = ThinkGeoLogType.Gpu;
ThinkGeoDebugger.LogStreamWriter = new StreamWriter("gpu.txt") { AutoFlush = true };

Thanks,
Ben

[Julian_Thoms]

gpu.txt (23.2 KB)

Here you go! If you need anything else - let me know. Code is the same as in Highlights are sometimes cut off against transparent background - #5 by Ben

[Ben]

Hi Julian,

Thanks to the log! it’s now fixed in beta172.

When we cut your highlight layers into tiles, a feature’s id was carried through only if it was a number. Yours are GUIDs, so each tile numbered its own features 1, 2, 3 - unique inside that tile and nowhere else. Your highlights span several tiles, so two of them arrived under the same id, and the label engine uses that id to recognize one feature across tiles: it kept the first and dropped the rest. Zooming re-cuts the tiles, so a different set collides each time.

Same root cause, same build: polygon labels are picked by that id too, and turning on GPU logging over a labelled polygon layer could crash the process. Both fixed.

You mentioned rings still cut off - does that still happen on beta172? The clipping fix
went in at beta169, so if it does, it is something else and I want a screenshot.

Thanks,
Ben

[Julian_Thoms]

Sweet, good find! This would have happened without a GUID too though if I understand it correctly.

Be aware that yes, we still see cut offs in the beta 171. The image I sent which shows cut off highlights was with beta 171.

I can check tomorrow with beta 172!

Thanks
J

[Julian_Thoms]

Here is an image of it happening in the latest beta now (174)

Those arent highlights, that’s just a WMS layer. seems like tile edges cut off features? Be aware, this is happening in CPU render.

Something similar seems to happen in your HowDoI sample as well:

[Ben]

Hi Julian,

Your last reply reveals two standalone issues.

1. Your WMS, cut at tile edges. Fixed in 15.0.0-beta175. A WMS draws each request on its own and clips at the edge, so a symbol near a tile edge lost half of itself. The layer now asks for a bit more ground than the tile and keeps only the tile, so the two halves meet. It is DrawingMarginInPixel on WmsAsyncLayer, 50 by default. Set it to 0 for the smaller requests.
2. “Yokohama” has its top sliced off. That is our basemap, not your WMS. We will dig in and figure it out.

Thanks,
Ben

[Julian_Thoms]

Thanks Ben! I dont get it though, wouldnt the other tile have the other half of the label anyway then after the cut?

[Ben]

Each tile is a separate GetMap request, and the server draws only what is inside the rectangle requested. A label belongs to a point, and that point sits in one tile, so the label will only be drawn in one tile, not the neighbor tiles. This is where the cut-off come from, and this is why DrawingMarginInPixel can fix this.

[Julian_Thoms]

Oh gotscha, i misunderstood how WMS works. That makes perfect sense now, thanks!

[Ben]

Awesome !

[Julian_Thoms]

And this is limited to GPU? Because I don’t see the same defect in CPU..?

GPU:

CPU:

Same extent btw - which is even more confusing, all points are bigger, there are points cut off etc. - I think the issue is something else.

We dug deeper and also found that only CPU render exposes the 50-pixel drawing margin while the GPU archive code currently uses a fixed 8-pixel buffer, and the runtime GPU cutter exposes no margin setting in beta191.

Here is the summary

FeatureLayer.DrawingMarginInPixel has no equivalent effect when using
FeatureLayerTranslator with the runtime GPU tile source.

Inspection of the installed beta191 assembly shows:

• A new classic InMemoryFeatureLayer defaults to a 50-pixel drawing margin.
• Neither the synchronous nor async feature-layer translation path reads
  DrawingMarginInPixel or forwards it to the tile source.
• FeatureSourceVectorTileSource and FeatureSourceVectorTileCutter expose no
  drawing-margin or tile-buffer setting. The cutter passes a literal 8 to
  VectorMbTilesLayerOptions and calculates its query padding as
  tileWidthInMapUnits * 8 / 512.
• Archive generation does expose VectorTileLayerOptions.TileBufferPixel.

Please expose a configurable runtime GPU buffer and make classic-layer translation
honor DrawingMarginInPixel, including the overloads accepting an existing source
and the async feature-layer overloads. Define how a changed margin invalidates
already-cut/cached tiles, or document any reopening requirement. Runtime cutting
and archive generation should have consistent pixel-buffer semantics.

[Ben]

Hi Julian,

Try beta192 — there is a good chance this is yours.

A circle is drawn outward from its anchor, and the anchor is in one tile only, so the neighbour has nothing to draw whatever the margin is. The owning tile has to be allowed past its own edge; it was, but only while it also owned the clip region for that ground, and sources drawn together share one clip region per cell. With a second source on the map, one of them never qualified and its circles kept being cut. Circles are not clipped to tiles at all now.

Your three points about the 8-vs-50 difference are all correct, I checked them — and they are the right explanation for the other kind of point, just not for circles. A square, star, image or glyph is drawn as an icon, and icons still clip at the tile edge, where the margin is exactly the lever.

Thanks,
Ben

[Julian_Thoms]

Hi Ben, sadly we still get the same issue?

What I can see here: The points seem to be cut off when there’s a different feature on the next tile?
Also: The image shown here in this WMS is still way larger than what is displayed when rendering in CPU.

See if you can reproduce that too - GPU same extent the WMS looks waay overblown.

[Ben]

Hi Julian,

Fixed in 15.0.0-beta196. It was the WMS layer, not your highlights — on GPU it asked the server for exactly one tile per request, so anything drawn near a tile edge got cut.

There is a property for it now, DrawingMarginInPixel on WmsRasterTileSource, 50 by default, the same name and default as WmsAsyncLayer. Set it if you prefer a different value:

Thanks,
Ben

[Julian_Thoms]

Thanks ben, that looks way better.

This did not address the second question - GPU shows way bigger points on the same extent compared to CPU.

I made you a repro of that:

FestpunkteWms.zip (7.4 KB)

Swap classic / gpu render and see size difference - zoom further out it’s even more obvious there.

[Ben]

Hi Julian,

It’s fixed in 15.0.0-beta200.

The GPU asked the WMS for 512 pixels per tile whatever the display, so on a scaled display every tile was magnified by the scaling factor - at 150% that is the half-again size you saw, and the further out you went, the coarser the picture the server was asked for, so it also drew fewer labels and simpler symbols than the classic layer got for the same extent. It now asks for each tile at the resolution of the screen, which is what the classic layer has always asked for, between zoom levels as well as on them. Running your project here with the two renderers side by side, the points measure the same.

Two more things came out of the same investigation and are in the build as well: during a zoom the GPU showed every earlier zoom’s tiles stacked under the loading ones, which on a transparent WMS appeared as huge blurred symbols until the new tiles arrived - one stand-in is drawn now; and a map whose vector layers are all hidden - which is how your repro starts, with the sample polygon off - reloaded its scene, WMS tiles included, every five seconds.

Thanks,
Ben