Failed to create surface

Question

Hello,

i bulild my project and get the following debug information when i start the system:

Create UI thread...                          [OK]
Initialize Display...                        [OK]
Initialize Touch Driver...                   [OK]
Initialize Memory Manager...                 [OK]
MemoryPool at address 0xC0177000 size 0x00689000
Initialize Graphics Engine...                [OK]
Create Embedded Wizard Root Object...        [OK]
Create Embedded Wizard Viewport...           [OK]
[ERROR in ewgfx.c:881] Failed to create surface with format: 0 and size ( 398 x 722 ).
Your application is now ready to use

The last information i added it by my self. The project is running without problem on my board, but obvious something went wrong in my code.

How can i locate the ERROR and find out what is my problem here. I looked through all my components and none ot it has the size of 398 x 722.

best regards

Torben

Answer 1

Hi Torben,

according the error message (and provided line number) I assume that there is a bitmap resource that cannot be loaded into the memory.

Does the error happen after your application runs some time or does the error happen during start-up?

You can try to reduce the surface cache to a small size (e.g. 0x10000) to avoid that large bitmaps remain in the memory after they are no more needed, which reduces the memory fragmentation.

In order to give you more hints, let me know the version you are using, the target and the color format.

Best regards,

Manfred

 

Comments

Hallo Manfred,

thanks for your answer. You were right, the problem was a bitmap resource. The bitmap was to large.

But just for curiosity, do i understand it right, that embedded wizard hold all bitmaps by default in the RAM? Or just the ones which are currently needed by the views, which are displayed.

Best regards,

Torben

---

Hi Torben,

only the bitmap resources that are currently needed (because they are referenced by an Image object) are loaded into the RAM. This means, all bitmap resources are loaded dynamically and decompressed during runtime. Otherwise - if all bitmap resources would be loaded during start-up - the amount of required memory would be tremendously...

The surface cache is used to keep unused bitmaps within the memory in order to avoid that they are reloaded again (as long as there is enough memory available).

Remark: The above described resource management is used for all compressed bitmap resources. If you are using direct access for bitmap resources, then they are stored uncompressed in the flash and they are drawn directly from flash memory. See attribute FormatOfBitmapResources.

Best regards,

Manfred.

---

Hello Manfred and Torben,

May I chime in here. We are experiencing the very same problem. Varying the size of the surface cache (up or down) apparently does not solve the issue though.

Since our GUI project has grown larger and larger, we start to experience this issue at startup, and indeed one bitmap (the background image) is missing. I can confirm Torben’s finding that the missing bitmap does not have the exact size the error message refers to.

We verified resource usage using EwPrintProfilerStatistics() and it seems there is enough RAM available (16 MB available, 6.3 MB used).

We are storing resources in ROM in compressed format. Obviously, when using uncompressed ROM storage instead, RAM requirements drop significantly, and in this configuration the error diappears.

Still, we need to understand what is the root cause of this issue. Possibly some configuration setting?

Best regards,

Steffen

---

Hi Steffen and Torben,

the error message appears, when the system runs out-of-memory while trying to allocate memory within RAM to decompress a bitmap resource.

The size is not "exactly" the size of the bitmap resource - the width and the height is two pixels larger. The reason is, that all bitmap resources contain a transparent frame of one pixel. This is necessary (or very advantageous from a performance perspective) when advanced graphics operations are done like rotation, scaling or perspective transformation.

So this should be very predictable - if you have completely other values for width and height, then we should investigate this deeper.

Concerning the memory consumption: If your system has 16 MByte RAM and there are only 6 MByte used and the system cannot allocate memory for a background image (e.g. 800x480 bitmap in RGBA8888 => 802x482x4 = 1510 kByte) during initialization, then there must be something going wrong...

Can you post the start messages and the profiler statistic?

Are you working with a customer specific hardware? If yes, can you ensure that the SDRAM is working properly (e.g. no refresh issues)?

Best regards,

Manfred.

---

Hi Manfred,

Thanks for clarification.

Bitmap size is understood now, and it corresponds to the size of our missing background image.

Concerning memory consumption, please find start messages and profiler statistics below:

Initialize Display...                        [OK]
Initialize Touch Driver...                   [OK]
Initialize Memory Manager...                 [OK]
MemoryPool at address 0xC0177000 size 0x00689000
Initialize Graphics Engine...                [OK]
Create Embedded Wizard Root Object...        [ERROR in ewgfx.c:881] Failed to create surface with format: 0 and size ( 802 x 482 ). [OK]
Create Embedded Wizard Viewport...           [OK]

147968 bytes occupied by 134 Chora objects
   26068 bytes occupied by 539 strings
 6335017 bytes occupied by Graphics Engine objects (without framebuffer)

TOTAL : 6509053 bytes, PEAK : 6509053 bytes

These messages are output by the application running on an STM32F769-DISCO board using the EmWi profile dedicated to this board. SDRAM size is 128 Mbit, so with no other large object residing there, plenty of space should be available -- but apparently there isn't. The memory pool appears to be 6.852.608 bytes in size, so the missing bitmap does not fit in there. But why isn't it made larger?

No risk of problems caused by custom hardware either (even though, obviously, we are in the process of designing a custom board, and we are well aware of this topic.)

Any ideas?

Best regards,

Steffen

---

Hello Steffen,

first of all, everything sounds reasonable...

If the memory pool contains 6852608 bytes and there are already 6509053 bytes occupied, there is not enough memory to load the full screen image.

The size of the memory pool is not defined or controlled by Embedded Wizard Studio - it is part of your application / initialization.

If you are using one of our Build Environments you will find the intialization of the memory pool within main.c. Please adapt the address and size of the memory pool according your memory layout.

Best regards,

Manfred.

---

Hi Manfred,

The memory pool definition is indeed the crucial point.
We are using the supplied Build Environment, and after modifying the definition (was 8 MB, now increased to 10 MB), the error is gone.

Thanks again for your support,

Steffen