Error when updating background image when offset

Question

Hi,

To align my GUI to the window in my product, I am offsetting the screen.

When I change the background (using the styles) I intermittently get the message:

[ERROR in ..\PlatformPackage\RGB888\ewgfx.c:1022] Failed to create surface with format: 0 and size ( 482 x 274 )]

It is not all images I have this problem with and ones that fail will work again later.

 

Any ideas?

Thanks, Phil

Answer 1

Hi Phil,

it seems that you are running out of memory due to memory fragmentation. Could this be the case?

When you change the background image, it might be the case that both images (the old one and the new one) are loaded into the memory.

You can do the following:

• If possible, you can increase the memory pool.
• When changing the background image, you can first assign null to the Bitmap property of the image and send an idlesignal to a slot method where you assign the new image to the Bitmap property. The idlesignal ensures that the new bitmap is assigned after the next screen update and after the garbage collector has freed the old bitmap resource.
• In order to reduce the fragmentation of the memory you can reduce the surface cache to 0 and build your project with the define 
  -DEW_MAX_SURFACE_CACHE_SIZE 0

Best regards,

Manfred.

Comments

Hi Manfred,

The memory pool is 4m - the double buffer so pretty big.

I have changed the cache to 0 and have set the image to null before updating on idle signal.

I still get the message, but less often.

The bit I do not understand is the size. My screen (and image) is 480 x 272 but the error message states a size of 282 x 274.

---

Hi Phil,

when you load a bitmap with the size 480x272 pixel, a buffer with 482x274 pixel is necessary, because there is a transparent border of one pixel arround the bitmap. This is necessary in case you are using this bitmap for warp operations.

What is the result when you are printing the memory statistics?

---

Hi Manfred,

I will give this a go. I assume I am best to call this where the error occurs in ewgfx.c?

The other thought I had is our GUI is layered, especially where the error occurs as I am stacking and removing layers. Could this be too much for the memory because it is holding the hidden layers?

---

Hi Phil,

you can print the statistics from the main loop (there you will find already the call to EwPrintProfilerStatistics() commented out).

Of course, when you have many components that are just invisible and they use a lot of resources, then the memory can be occupied by them.

Best regards,

Manfred.

---

Hi Manfred,

This is what is reported when the error occurs:

      28 object(s) of class 'Resources::Bitmap'
      13 object(s) of class 'Screens::SettingsMenuItem'
      13 object(s) of class 'Core::LayoutQuadContext'
      13 object(s) of class 'Core::LayoutContext'
       6 object(s) of class 'Resources::Font'
       4 object(s) of class 'Core::DialogContext'
       3 object(s) of class 'Graphics::Canvas'
       2 object(s) of class 'Core::StylesEvent'
       1 object(s) of class 'Application::DeviceClass'
       1 object(s) of class 'Screens::SplashScreen'
       1 object(s) of class 'Effects::FadeInOutTransition'
       1 object(s) of class 'Core::TaskQueue'
       1 object(s) of class 'Application::Application'
       1 object(s) of class 'Application::SDMClass'
       1 object(s) of class 'Effects::EffectTimerClass'
       1 object(s) of class 'WidgetSet::GaugeConfig'
       1 object(s) of class 'Screens::Dashboard'
       1 object(s) of class 'Effects::ShowHideTransition'
       1 object(s) of class 'Graphics::ArcPath'
       1 object(s) of class 'Views::FillPath'
       1 object(s) of class 'Screens::Settings'
       1 object(s) of class 'Effects::SlideTransition'
       1 object(s) of class 'Screens::SetColourScheme'
                      
   39376 bytes occupied by 97 Chora objects (peak 85448 bytes)
  14304 bytes occupied by 363 strings (peak 16710 bytes)
  1632403 bytes occupied by Graphics Engine objects (without framebuffer) (peak 2160785 bytes)
  368 bytes occupied by the profiler itself
                                
TOTAL : 1686451 bytes, TOTAL PEAK : 2218691 bytes

 

I does look to me like I need to flatten the structure so I am not holding so much in the background.

---

Do you have 4MB SDRAM or do you have a memory pool with 4MB?

Additional question: How much QSPI Flash does your system provide? Maybe the DirectAccess is an option (depending on the size of the images).