text graphics in scenes bug?

775
10
05-29-2019 10:22 PM
ioannisRoussos
New Contributor

I don't know if it is a bug or something else, but it's definetely unatural regarding text graphics in scenes and graphics overlays.

We are developing an app, it needs to be localized in various languages, so the text is added as a graphic in a graphics overlay.

 

I noticed profiling/debugging the app, that one sigle text label for a single graphic, after being rendered on the map adds about 300MB!!! of RAM to the app's total memory.

If the text graphic is created but not displayed the app memory is its normal size.

Styling settings don't make any difference.

It noticed with 100.5 runtime (for UWP), and I tested with 100.4 also.

0 Kudos
10 Replies
dotMorten_esri
Esri Frequent Contributor

How many graphics are you adding? Are you using the labeling engine to show text?

One thing to consider is that to render text symbol, a texture must be generated for each text symbol, and if there's a lot, and texts are long, it generates a lot of very large textures. That quickly adds up to a lot of memory, and even more-so on high-dpi devices (at least 4 bytes per pixel * pixel width * pixel height for each label).

The labeling engine handles these things a little better by being smarter about what to show (or not show).

0 Kudos
dotMorten_esri
Esri Frequent Contributor

Oh I just noticed you said "one single text graphic". Are you saying that you see a 300mb increase once you add a text graphic, or that the entire app uses 300mb? (and if you add a second one, it's yet another 300mb?)

0 Kudos
ioannisRoussos
New Contributor

Hello

The texture is a jpg file 32x32 pixels (and even that is cached in case of multiple graphics are added). The problem is not the graphics, it's the text.

Unfortunately the runtime for scenes(3D) doesn't support the labeling engine (I wish it did), so the labeling happens in a graphics overlay. Yes it adds 300MB additional RAM to the app (say it's ~200MB becomes 500MB).

Here's some code:

TextSymbol textSymbol = new TextSymbol                                              //create text
                {
                    Color = System.Drawing.Color.White,
                    Size = 18,
                    Text = location.Name,                                                         //localized string
                    OffsetY = 42.0,
                    HorizontalAlignment = Esri.ArcGISRuntime.Symbology.HorizontalAlignment.Center,
                    VerticalAlignment = Esri.ArcGISRuntime.Symbology.VerticalAlignment.Top
                };

 

                Graphic textGraphic = new Graphic(point, textSymbol);                              //create text graphic
                _graphicsOnScene.Graphics.Add(locationGraphic);                                   //add pin graphic in collection
                _graphicsOnScene.Graphics.Add(textGraphic);                                         //add location name in collection
                
                _sceneView.GraphicsOverlays.Add(_graphicsOnScene);                        //add collection in sceneview

I converted the text graphic in a DistanceCompositeSceneSymbol, just to delay the rendering of the label and observe. The moment the text is rendered, the memory spikes.

I'll experiment with more graphics on the map.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

Chatted with our 3D team. Supposedly the very first time you create a text graphic, it'll create a fairly large texture, which will be reused as more text symbols needs to be rendered, so there will be an initial hit the first time, but after that you shouldn't see it grow.

They were however rather surprised about the 300mb grows - could you share a little bit about your system (dpi, window size etc), that might help us better understand why it's so much.

I'm also curious what memory difference you see between adding/removing just this line of code:

      _graphicsOnScene.Graphics.Add(textGraphic);   

Also are you seeing another 300mb be used when you add the second textGraphic. or is it a much smaller increase after that point?

0 Kudos
ioannisRoussos
New Contributor

I experimented a bit, this time I labeled features using textgraphics (not the label engine).

About 50 features labeled in 1 overlay, so 50 text graphics not more than 20 characters long strings and I can confirm that the memory doesn't grow exponentially (the RAM grows once).

If the textgraphic is created but not displayed it doesn't affect the memory growth, it's only when the text is diplayed, so if you comment out that particular line of code (adding it in the overlay), the memory will be normal.

Please, check out the screenshots from debugging seesion, I placed a break before (1st screenshot) and the 2nd screenshot is just after executing it.

 

It's a UWP app, the issue was unoticed on a physical device, I noticed debugging on my dev pc. The window size doesn't affect anything even at full size (2560x1080) and the labels are short strings.

0 Kudos
JimSchindling
New Contributor II

I am seeing the same issue. Has anyone come up with a solution or work-around?

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Hi Jim,

Please can you provide more details on the issue you're seeing and ideally share a small, self-contained reproducer app that will help us reproduce and investigate?

Are you using the latest version, 100.9?

Thanks

Mike

0 Kudos
JimSchindling
New Contributor II

Hi Mike,

Thanks for getting back to me so quickly.

I’m am currently using 100.7

I will have to put together a little app for you, but it’s exactly the issue that was described in the forum except I am building a WPF app rather than UWP.

Do you know if there may be any changes in 100.9 that are related to this issue?

Thanks again,

Jim

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Jim,

Version 100.8 included an enhancement in the area of rendering Graphics with TextSymbols in 3D (SceneView), specifically intended to improve resource management. Version 100.9 also included enhancements to graphic and symbol performance in both 2D and 3D.

Thanks

Mike

0 Kudos