Edge 1050 datafield and Custom Fonts

I just want to ask, if anybody else has faced this problem:

It occurs on using custom fonts, but only on device Edge 1050, and it happens every now and then. It is definitely not a code error, because - as I sayd - it happens now and then, but only with Edge 1050:

Line 3349 is the first appearance of using the custom font myTINY_T  in onUpdate(dc) :

dc.drawText( 10, 5, myTINY_T, "GPS", textCenter);
  
...and this font is loaded in initialize() without error:
myTINY_T = WatchUi.loadResource(Rez.Fonts.id_font_myTINY_T5);
  
Has anybody else seen this problem with custom fonts on Edge 1050?
  • Just a guess, but maybe the graphics pool is involved.  It's a fixed size and shared by all apps on the device, and things like custom fonts and bitmaps are stored there and not in an apps own memory..

  • Ok, that‘s a good point!

    To find out a solution, I added a check, if myTINY_T == null before using, but it is not null when it happens.
    So, loading the font throws no error, and the variable (which is initialized with null) is not null anymore - but throws the error.

  • Probably there is no possibility to check the current used memory of the Graphics Pool?
    (and do we know the size of GP?)

  • I've never seen a way to check either the size or how much is used.  For me, I tend to only use custom fonts in watch faces, and then not too may or too large, (2 or 3, with only 1 with a large font, that only is used to display the time so not many characters.

  • It‘s strange, that it never happens with Edge 1040. Only Edge 1050 are affected. They both have Graphics Pool. Different memory size? 

  • Could be a bug specific to the 1050, or could have to do with whatever other apps are using it, as it is shared,

  • can you catch an exception in the rare case that the loadResource isn't successful? strange that symbol isn't found? if it was null that would be a different error?

  • It's not loadResource() that's crashing, it's dc.drawText() in onUpdate().

    Despite the stack trace, it's probably not literally crashing on the actual call to dc.drawText(), but likely in CIQ API code within drawText (or called by drawText). (It's fairly common that the stack trace will seem to point to a line of code in the app, when it's actually code in the API that's failing.)

    If myTINY_T was null, it would be different error. But it should be completely within the control of the app whether myTINY_T ever becomes null or not (following loadResource), so a problem of that nature would probably be easier to track down (and probably not be confined to edge1050)

    What seems to be happening: loadResource returns a FontReference on CIQ 4+ devices, which is actually a reference to the graphics pool, and there's possibly a bug in edge1050 which causes an access of a valid graphics pool reference to crash. (i.e. perhaps the font resource has been automatically unloaded from the graphics pool, but the graphics pool is unable to reload it when necessary)

    One way to workaround this problem could be to "lock" the font resource in the graphics pool by calling get() on the FontReference, storing the result (a FontResource) persistently in app memory, and passing the FontResource to drawText. Few problems with this:

    - if the app supports CIQ < 4, this code would have to be called conditionally (since there's no graphic pool or related resource reference types in CIQ < 4)

    - this would waste memory, defeating the purpose of the graphic pool by keeping a resource "locked" in the pool for as long as the app is active

  • Thank you, that is a good and probably accurate explanation. It does seem to be a glitch in the graphics pool of the Edge 1050.
    Since it might not be reproducible or only with great difficulty, we'll probably have to live with it...

  • Idk, might be worth filing a bug report anyway, to bring it to the attn of the ciq team, especially if it really is a problem that's specific to edge1050.