This option is controlled by the macro 'EW_PRINT_MEMORY_USAGE'. To activate it, you need to define this macro in your project settings and force the entire project to be rebuilt. In case of a Win32 executable, the outputs are shown in the additional console window. Following when you start the application executable an additional console window is opened (may be in the background of the viewer window). In this console window all debug and trace messages are written repeatedly (as an example):
9804 bytes occupied by 21 object(s)
1572 bytes occupied by 55 string(s)
1927724 bytes occupied by Graphics Engine objects
168 bytes occupied by the profiler itself
TOTAL : 1939268 bytes, PEAK : 1939436 bytes
The first row describes how much memory is occupied by Chora objects. The second row refers to the memory used by decompressed strings (before strings are used they are decompressed block-wise). The third row describes how much memory is used by resources. In particular the memory needed for the off-screen buffer can be found here. Exactly for this reason the value can become very large (e.g. screen 800x600 pixel with 32 Bit RGBA per pixel = 1920000 bytes).
This memory usage monitoring works similarly on the target system. You can e.g. add the macro to your make file and after recompiling the project the memory usage is output in the 'stdout' stream of the started application. Please note, that depending on the target system it is possible that not all graphical memory is covered by our measures. In particular we not always know about memory used internally by the underlying graphical subsystems, etc.
Additionally please note, that on the embedded target system you evtl. may need to add following line of code to your main() function in order to print the collected information. Usually this function is executed each time the GUI application loops in the event loop (it performs the screen update):
EwPrintProfilerStatistic( 0 );
