How is glyph cache managerd?

Question

Dear EW Experts,

I have encountered a problem  in drawing text, some multi-language font sometimes can not be correctly rendered. After adding some debug log, I  found them fail at：

 EwCreateGlyph()

       FindFreeGlyphCacheArea()

the result is zero, means no space avaliable in glyph cache.

My question is, why would this happen? I remember there is garbage collection in ew frwk, I doubt that the glyph cache is not managed by garbage collection mechanism, if so, how should we manage our glyph, how do we discard a glyph in cache?

-------------------------

p.s.  currently, only arabic language is likely to encounter this issue

arnold

Answer 1

Hello Arnold,

first of all, there should be no need discard glyphs somehow manually from the cache - the glyphs remain as long as possible in the cache and will be discarded automatically when new glyphs have to be loaded and no empty space is found.

Anyhow, can you describe more details about your system: Versions, Target, Color Format, Configuration (ewconfig.h) and Error Description - then it will be easier to help you.

Best regards,

Manfred.

Comments

version 11.00
platform package: generic software ttfe rgba8888

direct error is: EMWI ERROR: code:181, infol: "FontsSize200Default"，info2:49"

I have added some extra log, and found it firstly failed at:

So my question is , if we can discard the older glyphs in cache, why would this failed?

---

What are the parameters of FontSize200Default?

How is your glyph cache configured (ewconfig.h)?

---

Hi，

The main parameters of FontSize200Default are:

• Height: 200
• HeightMode: Popular
• Ranges: (basically some marks and figures character)

And we didn't change any configuration about glyph cache, it now runs with the default values.

Besides, we think that FontSize200Default is not the key point of this issue, we've found that if we use fonts with other language, such as Japanese or Chinese (work with FontSize200Default too), this issue won't happen at all. Therefore, we strongly believe this issue must have something with Arabic.

Moreover, we wonder how the mark-as-in-use logic works, because we think this logic doesn't work normally with Arabic Characters, could you tell us about this or check if this issue really exists?

---

Hello,

the function EwCreateGlyph() may fail. It is fully legal if there is no more space in glyph cache. In such situation the superior function reacts and flushes pending drawing operations repeating then the operation again. This should have the effect of all affected glyphs being released in the glyph cache. New glyphs can be loaded thereupon.

See the following screenshot from the function EwDrawText() (version 13). It invokes GetGlyph() which internally invokes EwCreateGlyph(). When no glyph is obtained, EwDrawText() flushes the actually prepared drawing operation and repeats the task again:

Therefore, we strongly believe this issue must have something with Arabic.

Could you please provide us a call history leading to the error? If the error is reproducible, it would be helpful to have a small example demonstrating the issue.

Best regards

Paul Banach

---

Hi,

We do understand how the cache works, but the key point is that it didn't work normally in our use case. 

We're sure that we've removed all old components with Arabic text from root, according to the cache logic, when we create a new component with Arabic text, it will discard old characters from cache and create a new one. In fact, it failed, due to no space on cache surface. Sadly, we are using version 11.0 now, and there is no such code in corresponding function. The code in version 11.0 will just end the loop and end up with a Error Code: 181 / 182.

Therefore, do you mean that the highlight part of your screenshot will handle this issue ? which is not exist in version 11.0, if yes, could you please tell us how to make it in version 11.0 ?

Could you please provide us a call history leading to the error? If the error is reproducible, it would be helpful to have a small example demonstrating the issue.

 

As for this part, it's hard to provide those logs to you due to some audit request. Anyhow, this is a good idea, we'll try create a small project to test this logic, and check whether the logic of gfx works good with Arabic.

Thanks for your kindly reply.

BR，

Jacob Wang

---

Hello,

similar handling is also found in older versions. Due to adaptations for complex text shaping the implementation was changed in versions 12 and 13. For the version 11:

... we'll try create a small project to test this logic, and check whether the logic of gfx works good with Arabic.

That would be helpful to understand the conditions leading to this behavior.

Best regards

Paul Banach