C++ SDK \ WIP Garbled text displayed


I have a CRhinoUiFontComboBox and handle the ON_CBN_SELCHANGE messages to get user selected fonts. As I scroll through all the various fonts, my text is displayed in a conduit. This works fine for a while but after continued scrolling, some of the displayed text begins to appear garbled as shown below.

The top font happens to be Copperplate Gothic Bold and the bottom is Copperplate Gothic Light. As I continue to scroll, some fonts will be fine and others are not. Once a font turns garbled, that particular font will always appear that way when I return to it after scrolling to other fonts. If I close the application and then launch it again, everthing works fine for a while, then repeats the problem. The text is not improved if I add it to the Rhino document.
This is my first attempt at using the new V6 text, so I may be creating it wrong. Here is how I do it:

//Create font from face name retrieved from ComboBox.
const ON_Font* font_ = ON_Font::GetManagedFont(face_name, b_bold, b_italic); 

//Set my ON_DimStyle object.
style  = doc->m_dimstyle_table.CurrentDimStyle().CreateOverrideCandidate();

//Create ON_Text object.
ON_Text txt;
txt.Create(my_wchar, &style, plane);

//Display text in conduit or add text to document.
dp.DrawAnnotation(txt, Black, p_updater, &h_cache);
doc->AddTextObject(txt.RichText(), txt.Plane(), txt.Plane().Origin(), &style);

(Dale Fugier) #2

Hi @Gary,

Is it possible for you to post some sample that we can use to repeat the problem you are seeing?


– Dale



This code is part of a larger program, but I will try to write a simple example and see if the problem repeats.

Thank you.

(Dale Fugier) #5

Hi @Gary

I am not able to reproduce the drawing issue here. We suspect this is an OpenGL shader issue. I’ve opened an issue on this:


To assist the developer, who will look at this, in solving this issue, can you paste the results of Rhino’s SystemInfo command into a reply to this?

Also, in looking at your drawing code you are drawing annotation text in a depth-buffered channel. This is why you need to call CRhinoDoc::Regen to see the changes. For better performance, try drawing in the CSupportChannels::SC_DRAWOVERLAY channel. In doing this, you can then just call CRhinoDoc::Redraw.

I’ve attached a sample project that demonstrates this.


– Dale

SampleDrawAnnotation.zip (18.7 KB)


Thanks for the code. I tried several display channels and redraw functions to try and correct the problem but nothing worked. I am getting the same garbled text with your sample code. Scrolling through the font ComboBox, I leak about a GB of memory and closing the plug-in dialog doesn’t return the memory. Also, any text that I subsequently add to the document using Rhino commands is also bad.

In your example code you are using the ON_Text::BoundingBox() function in your conduit. This seems to work fine to get the basic text size but I notice that this won’t return the actual size of text with a modified style that changes the text size such as setting the text height or just using italic. Is this a bug or do we need to use ON_Text::GetAnnotationBoundingBox(), which does seem to return the correct size?



Any progress with this? I am still seeing the garbled text and the one gigabyte memory leak.

(Dale Fugier) #9

Hi Gary,

The font garbling that you see is a OpenGL shader issue. It’s been reported a few times in in the Serengeti category.

What video card to you have? Can you run the SystemInfo command and paste the OpenGL section in a reply?

Also, when you create fonts in Rhino, they are cached so they can be quickly retrieved for later use. I am assuming this is the memory usage you are seeing.

– Dale



My SystemInfo was submitted and attached to the original RH-41674 issue report which you generated for this bug.

This is a very large memory commitment just to preview the font. It would be nice to have an SDK method to release the memory for situations like this.

– Gary

(Dale Fugier) #11

Hi Gary,

I’ve logged a bug for this:


As I mentioned earlier, Rhino 6 caches fonts and glyphs, so as to improve performance. But I think we can do better in some cases, such as the dynamic UI demonstrated by the C++ code in this thread.


– Dale