View Issue Details

IDProjectCategoryView StatusLast Update
0002255NoesisGUIC++ SDKpublic2025-10-30 11:07
Reportersteveh Assigned Tojsantos  
PrioritynormalSeveritytrivial 
Status feedbackResolutionopen 
Product Version3.2.0 
Target Version3.2.0 
Summary0002255: Stroke bug - bad path generation
Description

Hi guys, we're seeing bad strokes caused by our fonts. It seems that the path it rasterises does not match the font glyph shape. I've attached a ZIP which you can use to see our font. Pay attention to the "A", you can see that the stroke in the centre looks odd.

Some glyphs are worse than others. We can play about with the stroke thickness to improve things somewhat, but I'm wondering if something is going wrong in the stroke generation code where it's generating bad paths.

I've also uploaded an image of this in case you didn't want to build the sample.

Cheers,

-Steven

Steps To Reproduce
  1. Extract the ZIP into the Native Noesis SDK folder.
  2. Generate the config I attached
  3. Build and run the "FontStrokeBug" sample I added
  4. Notice the artifacts in the strokes around the font glyphs. The fonts are pixel perfect but the strokes have artifacts in them where they "bleed" into other strokes and don't match the font path exactly
Attached Files
StrokeBug.zip (59,217 bytes)
BadStroke.png (214,540 bytes)   
BadStroke.png (214,540 bytes)   
PlatformAny

Activities

jsantos

jsantos

2022-02-01 10:57

manager   ~0007762

Hi Steve,

This seems to be SDF imprecisions. I will analyze it carefully, but probably we will need to increase SDF resolution.

Is this happening on trunk or in the Arabic branch?

steveh

steveh

2022-02-01 11:03

reporter   ~0007763

Hey Jesus, yes, this is in the Arabic branch, but I'm pretty sure this issue was present in the build prior to integrating the Arabic branch as well.

jsantos

jsantos

2022-02-01 11:06

manager   ~0007764

Yes, that makes sense.

I am finishing an important crash you have in the Arabic branch (VGLTextLayout::HitTestTextPosition) and will jump to this ASAP.

steveh

steveh

2022-02-01 11:09

reporter   ~0007765

Awesome, much appreciated. And yes, those HitTestTextPosition bugs take precedence over this issue for us, this is just a slight graphical issue that's fairly low priority, the other issues are causing glyphs to be rendered in the incorrect location so we're getting overlapping prompts which will cause compliancy failures.

Thank you for your help Jesús! Much appreciated.

jsantos

jsantos

2022-02-15 15:09

manager   ~0007809

Last edited: 2025-10-30 11:07

Hi Steve, I see similar artifacts even without stroking. This is a limitation of the current technique we are using for rendering text, each font is internally rasterized to a distance field of size 54. If you double this size, you will see everything improves:

Index: VGLContext.cpp
===================================================================
--- VGLContext.cpp  (revision 11207)
+++ VGLContext.cpp  (working copy)
@@ -3709,7 +3709,7 @@
 #if 1
     // Render glyph SDF at a fixed resolution
     NS_UNUSED(scale);
-    float renderSize = 54.0f;
+    float renderSize = 54.0f * 2;
 #else
     // Render glyph SDF at the next power of two needed resolution
     float renderSize = (float)Clip(NextPow2(uint32_t(p.size * scale)), 1U, 54U);

But doing this has tricky implications. Right now, by default our glyph cache uses an internal texture of 1024 x 1024 with tiles of 512 x 512 (tiles are entirely discarded when there is not enough space in the atlas using a LRU algorithm).

The resolution of 1024 x 1024 can be changed by clients (not sure if your game is doing that), but the 512 x 512 is hardcoded in a macro (TILE_SIZE). The patch provided above should probably also increase TILE_SIZE. But this also depends on how heavy is your game about text.

Not sure yet what's the best way to expose this to client code. Tile size can be exposed the same as atlas size, and probably we can expose a size threshold for glyphs, if the size of the glyph (in your case is 200) is greater than that we can increase the rasterized distance field.

I need to think more about this, but feedback is welcome.

PS: thanks for the amazing repro-case, as always, you always make things so easy for us :)

Issue History

Date Modified Username Field Change
2022-02-01 03:39 steveh New Issue
2022-02-01 03:39 steveh File Added: StrokeBug.zip
2022-02-01 03:39 steveh File Added: BadStroke.png
2022-02-01 10:55 jsantos Assigned To => jsantos
2022-02-01 10:55 jsantos Status new => assigned
2022-02-01 10:57 jsantos Note Added: 0007762
2022-02-01 10:57 jsantos Status assigned => feedback
2022-02-01 11:03 steveh Note Added: 0007763
2022-02-01 11:03 steveh Status feedback => assigned
2022-02-01 11:06 jsantos Note Added: 0007764
2022-02-01 11:07 jsantos Product Version => 3.2.0
2022-02-01 11:07 jsantos Target Version => 3.2.0
2022-02-01 11:09 steveh Note Added: 0007765
2022-02-15 15:09 jsantos Note Added: 0007809
2022-02-15 15:09 jsantos Status assigned => feedback
2022-02-15 15:09 jsantos Note Edited: 0007809
2022-02-15 15:10 jsantos Note Edited: 0007809
2025-10-30 11:07 jsantos Note Edited: 0007809