3.1.3 using BufferedBitmap (with the full palette for Anti Aliasing)

I also can't use older SDKs since updating to the new Eclipse plugins: https://forums.garmin.com/developer/connect-iq/f/discussion/191113/3-1-3-sdk-hotfix-for-fenix-6-issues/931868#931868

And I've also realised there is no way I can get my watchfaces to run on the Fenix 6X! I only use a small offscreen buffered bitmap but scaling that and the rest of the graphics up would require at least an extra 7kB.

el34rob2 - are you using a palette for the buffered bitmap?  If I limit the palette it works fine, too, but then the fonts cannot be antialiased.  This is the issue I'm having.  Also the same code seems to use considerably more RAM than the with the previous SDK.

Hi KSodhi, no I'm not using a reduced palette.  Like you, I want to use anti-aliased fonts.  If you're creating your buffered bitmap using dc.getWidth() and dc.getHeight() then its always going to use more memory when you move from a device with 240X240 to 260X260 pixel resolution.

el34rob2 - agreed and understood.  dc.getWidth() and dc.getHeight() are needed to accommodate a variety of  devices.  The point I'm trying to make is that with the new SDK even my existing 240x240 watches are out of memory, I can understand if 260x260 or 280x280 were a problem with respect to the buffered bitmap.  But the fact that I can't get the 240x240 working means that, on this SDK, the rest of the code is demanding more memory, even if the bitmap size is the same. 

Travis.ConnectIQ has already pointed this out above. 

Given that I can't revert the SDK to a prior version, I can't do an analysis on where that extra RAM is being consumed.

Since the old sdk you say is only consuming 85kb and with the new sdk its around 100kb, but from your screenshot it looks as if the bufferedbitmap is consuming the correct amount of memory ~57kb. It could very well be that something else is consuming the memory instead of the bitmap. It could be a change in the api or a bug, I would try to sum up all the objects and see which objects other than the bitmap is consuming an unusually high amount of ram. The difference between 100kb and 85kb is large and might be easy to spot.

KSodhi said:

Given that I can't revert the SDK to a prior version, I can't do an analysis on where that extra RAM is being consumed.

The easiest thing to do is to get yourself a second (or third, or Nth) eclipse install. If you download the .zip (from here would work), you can extract the zip file into folders with various names (i.e., eclipse-connectiq-3.1.3, eclipse-connectiq-3.0.12, ...) and then you can configure each of them to use version-appropriate plugin as you need.

You shouldn't need to do all of this, but it will work...

KSodhi said:

I can't seem to switch back to using an older SDK either - not sure if it's the additional resource-280x280 folders or what, but the following error comes up: 

This happens when the manifest.xml has references to devices that aren't supported by the SDK you've selected. If you open the manifest editor, click the manifest.xml tab, and save, it will strip out the devices that don't belong.

We have an issue filed to fix this (it is quite frustrating when you frequently flip between SDK versions). I hope the fix will be to simply ignore unknown device names, but we'll see.

Exactly, I am getting an "Out Of Memory" Error on Fenix 6/6X for the same code which is running smoothly on older devices!

But I didn't want to give up. I found that the biggest possible BufferedBitmap which can still fit into the memory (without limiting the palette) is 250x250 in my case. So I have used what's available, I limited the offscreen buffer for the bigger displays and this is the result with smooth antialiased fonts together with 1Hz analog second hand on Fenix 6 (260x260) and Fenix 6X (280x280). ;)

SecondHand PRO

Nevertheless, I really hope that Garmin will gave as more RAM on new devices soon.

Don't forget, the f6 isn't the only new watch that 260x260.  The va4 is also that size, as is First Avenger