crash with two rendering threads using text rendering (freetype)

Support
1

I think I’m currently hitting this old bug; I’ve commented on it, but I’m not sure anybody will see it there.

My issue: I run two separate render threads, one addressing a VR render window, the other addressing screen rendering; and whenever both threads have to render a text (the same one, actually), either one of them spuriously hits some nullptr glyph in vtkfreetype-…dll. A call stack of one of these crashes (they sometimes occurred at different positions as well I think, I’ll keep you posted):

vtkfreetype-9.4d.dll!ftc_inode_weight(FTC_NodeRec_ * ftcinode, FTC_CacheRec_ * ftccache) Line 118
vtkfreetype-9.4d.dll!ftc_node_destroy(FTC_NodeRec_ * node, FTC_ManagerRec_ * manager) Line 296
vtkfreetype-9.4d.dll!FTC_Manager_Compress(FTC_ManagerRec_ * manager) Line 568
vtkfreetype-9.4d.dll!ftc_cache_add(FTC_CacheRec_ * cache, unsigned __int64 hash, FTC_NodeRec_ * node) Line 435
vtkfreetype-9.4d.dll!FTC_Cache_NewNode(FTC_CacheRec_ * cache, unsigned __int64 hash, void * query, FTC_NodeRec_ * * anode) Line 470
vtkfreetype-9.4d.dll!vtkfreetype_FTC_CMapCache_Lookup(FTC_CMapCacheRec_ * cmap_cache, void * face_id, int cmap_index, unsigned int char_code) Line 268
vtkRenderingFreeType-9.4d.dll!vtkFreeTypeTools::GetGlyphIndex(unsigned __int64 tprop_cache_id, unsigned int c, unsigned int * gindex) Line 826
vtkRenderingFreeType-9.4d.dll!vtkFreeTypeTools::GetBitmap(unsigned int c, FTC_ScalerRec_ * scaler, unsigned int & gindex, FT_BitmapGlyphRec_ * & bitmap_glyph) Line 2291
vtkRenderingFreeType-9.4d.dll!vtkFreeTypeTools::CalculateBoundingBox(const std::string & str, vtkFreeTypeTools::MetaData & metaData, const std::string & defaultHeightString) Line 1372
vtkRenderingFreeType-9.4d.dll!vtkFreeTypeTools::CalculateBoundingBox(const vtkStdString & str, vtkFreeTypeTools::MetaData & metaData) Line 1317
vtkRenderingFreeType-9.4d.dll!vtkFreeTypeTools::GetMetrics(vtkTextProperty * tprop, const vtkStdString & str, int dpi, vtkTextRenderer::Metrics & metrics) Line 520
vtkRenderingFreeType-9.4d.dll!vtkMathTextFreeTypeTextRenderer::GetMetricsInternal(vtkTextProperty * tprop, const vtkStdString & str, vtkTextRenderer::Metrics & metrics, int dpi, int backend) Line 154
vtkRenderingCore-9.4d.dll!vtkTextRenderer::GetMetrics(vtkTextProperty * tprop, const vtkStdString & str, vtkTextRenderer::Metrics & metrics, int dpi, int backend) Line 196

Does anyone have an idea how I could quickly fix / work around this problem? Splitting up the application into a screen rendering and a VR rendering part (which also means having to introduce messaging between the two) does not sound like an appealing option at this point as it would be a very time-consuming endeavour…

Any text rendering in VTK is probably using freetype, so I cannot avoid using it if I want to show some text I guess?

2

Hello,

My two cents: as far as I know vanilla VTK is not fully thread safe. Have you considered VTK-m?

best,

PC

1 Like
3

Thanks for that input - no I hadn’t thought of that. How would I go about that exactly? You mean replacing VTK rendering with vtk-m rendering facilities?
Actually, so far I had been under the impression that vtk-m was “just” providing parallelized versions of filters. Only on checking after your comment, I realized that it also includes rendering facilities. Might be an interesting way to go.

However, reading the rendering section in the vtk-m user guide, I saw the following note:

Because VTK‑m is designed to be integrated into larger systems, it does not aspire to have a fully featured rendering system.

Because of this, and because a quick search on “migrating from VTK to vtk-m” and variations did not give any clear results, I’m a bit doubtful that this would be a simple drop-in replacement procedure. I therefore guess that rewriting everything to use vtk-m instead of VTK would also be a major endeavour which I’d like to avoid.

4

So, do you really need multithreaded rendering? If you do need it, you may end up enclosing certain calls (e.g. renderer->Render()) within critical sections, so, you will likely end up with a more complicated code without any real speed up.

5

The ancient vtkTextSource class in VTK doesn’t use freetype. It’s limited to ASCII (or maybe latin1, I’m not sure) and it’s rough around the edges, but it might fit your requirements. It can be used with vtkFollower to make the text face the camera.

1 Like
6

Ah, there’s also vtkVectorText (also limited to ASCII). Even though it’s in Rendering/FreeType, it doesn’t use freetype at all, it uses hard-coded shapes for the letters.

1 Like
7

vtkTextActor3D and vtkLabeledDataMapper can support font setting.