# Glyph Memory Allocation

**URL:** <https://forum.juce.com/t/glyph-memory-allocation/15735>\
**Category:** General JUCE discussion\
**Created:** [October 20, 2015, 8:28am UTC](https://forum.juce.com/t/glyph-memory-allocation/15735 "2015-10-20T08:28:35Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![LukeM](https://avatars.discourse-cdn.com/v4/letter/l/f04885/32.png) [@LukeM](https://forum.juce.com/u/LukeM)\
**Post date:** [October 20, 2015, 8:28am UTC](https://forum.juce.com/t/glyph-memory-allocation/15735/1 "2015-10-20T08:28:35Z")

</div>

Hi all,

I've been experimenting with drawing in to a cached Image on my own Thread to keep complicated draw routines off the Message Thread, and I have discovered some strange memory behaviour in the OSXTypeface. &nbsp;Just to note that I'm seeing this using the tip of the Juce repo.

&nbsp;

When drawing in to a Graphics object generated on a Thread which isn't the Message Thread (i.e. not one handed to the Component::paint() method), I am seeing constant allocation of memory stacking up over time in the OSXTypeface::getGlyphPositions method.

To be clear, this is NOT a memory leak. The memory is all freed correctly when the app is closed.

&nbsp;

The problem appears only when I use one of the text drawing methods of the Graphics object.

&nbsp;

Below is the simplest way to recreate the issue, simply place this in to a GUI App and attach Instruments (look for \_\_NSDictionaryl):

```
MainContentComponent::MainContentComponent()
    : m_Image(Image::ARGB, 600, 400, true)
    , m_Lock()
{
    setSize (600, 400);

    // Start the timer which will repaint the Image.
    Timer::startTimer(20);

    // Start the timer which will actually draw the Image.
    HighResolutionTimer::startTimer(20);

}

MainContentComponent::~MainContentComponent()
{
    Timer::stopTimer();
    HighResolutionTimer::stopTimer();
}

void MainContentComponent::paint (Graphics& g)
{
    ScopedLock lock(m_Lock);

    // Here, we just draw the Image which has been drawn in to elsewhere.
    g.drawImageAt(m_Image, 0, 0);
}

void MainContentComponent::timerCallback()
{
    // Ensure that all calls to repaint()/paint() happen on proper Thread.
    repaint();
}

void MainContentComponent::hiResTimerCallback()
{
    ScopedLock lock(m_Lock);

    // Here, we are creating a temporary Graphics context and drawing some text into it.
    Graphics g(m_Image);    

    g.fillAll (Colour (0xff001F36));

    g.setFont (Font (16.0f));
    g.setColour (Colours::white);
    g.drawText ("Hello World!", getLocalBounds(), Justification::centred, true);
}
```

&nbsp;

There is a screenshot here:&nbsp;http://postimg.org/image/ug5pul53b/ &nbsp;which shows the increasing memory allocation, etc.  
&nbsp;

---

<div class="post-metadata">

**Author:** ![fr810](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/fr810/32/841_2.png) [@fr810](https://forum.juce.com/u/fr810)\
**Post date:** [October 20, 2015, 5:02pm UTC](https://forum.juce.com/t/glyph-memory-allocation/15735/2 "2015-10-20T17:02:52Z")

</div>

Hi LukeM,

I was able to reproduce your bug, however, I cannot find anything wrong with the JUCE code. The function causing the memory increase is&nbsp;CTLineCreateWithAttributedString which seems to be retaining the NSString which refers to the attribute's name. As far as I can tell it's never released. There are a few posts on stack overflow complaining about similar problems. Does anybody have a workaround for this? Sorry that I don't have any better news for you :-(.

Fabian

---

<div class="post-metadata">

**Author:** ![LukeM](https://avatars.discourse-cdn.com/v4/letter/l/f04885/32.png) [@LukeM](https://forum.juce.com/u/LukeM)\
**Post date:** [October 21, 2015, 10:57am UTC](https://forum.juce.com/t/glyph-memory-allocation/15735/3 "2015-10-21T10:57:30Z")

</div>

Hi Fabian,

Thanks for reply; that is indeed not good news!

&nbsp;

However, I have discovered that setting JUCE\_CORETEXT\_AVAILABLE to 0 makes the problem go away. Is there any reason I shouldn't be doing this?

&nbsp;

Thanks again,

Luke.

---

<div class="post-metadata">

**Author:** ![fr810](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/fr810/32/841_2.png) [@fr810](https://forum.juce.com/u/fr810)\
**Post date:** [October 21, 2015, 2:52pm UTC](https://forum.juce.com/t/glyph-memory-allocation/15735/4 "2015-10-21T14:52:00Z")

</div>

See [line&nbsp;1025 of juce\_mac\_Fonts.mm](https://github.com/julianstorer/JUCE/blob/master/modules/juce_graphics/native/juce_mac_Fonts.mm#L1025)which is the fallback when CoreText is not available (or when&nbsp;`JUCE_CORETEXT_AVAILABLE i`s 0). For example, getOutlineForGlyph won't work on iOS (see the return false) and uses a hack on OS X&nbsp;where it draws the glyph into a bezier path and then tries to interpret the bezier path. I haven't tested the performance but wouldn't be surprised if this workaround is&nbsp;many times slower than using CoreText.