This option is controlled by the macro 'EW_PRINT_GFX_TASKS'. To activate it, you need to define this macro in your projects settings and rebuild the entire project. Similarly to the monitoring of the memory usage, the outputs are shown in the additional console window (in case of a Win32 executable).
The following example demonstrates the possible outputs:
ELIMINATE TASKS: 18(-3) Overwrite: 13838(-69.62%) Blend: 18017(-25.52%)
EXECUTE TASKS for surface 0x00919EE8
{
LockSurface( 0x00919EE8 )
LockSurface( 0x00993BA8 )
CopySurface( 0x00993BA8, ( 432, 68 )-( 506, 140 )=( 74 x 72 ), OVER ) SW
UnlockSurface( 0x00993BA8 )
LockSurface( 0x00910E48 )
DrawText( 1 glyphs, ( 495, 103 )-( 506, 125 )=( 11 x 22 ), BLEND ) SW
DrawText( 1 glyphs, ( 486, 80 )-( 497, 92 )=( 11 x 12 ), BLEND ) SW
UnlockSurface( 0x00910E48 )
[...]
UnlockSurface( 0x00910E48 )
LockSurface( 0x009A8FF8 )
WarpSurface( 0x009A8FF8, ( 200, 97 )-( 273, 139 )=( 73 x 42 ), BLEND ) SW
UnlockSurface( 0x009A8FF8 )
LockSurface( 0x009A9EF0 )
CopySurface( 0x009A9EF0, ( 200, 68 )-( 274, 139 )=( 74 x 71 ), BLEND ) SW
CopySurface( 0x009A9EF0, ( 200, 139 )-( 274, 161 )=( 74 x 22 ), OVER ) SW
UnlockSurface( 0x00919EE8 )
UnlockSurface( 0x009A9EF0 )
}This outputs describe the transactions at the lower interface to the underlying graphics sub-system. Each row describes the kind of the operation (e.g. CopySurface -> copy a rectangular area from one surface to other). The keywords 'OVER' and 'BLEND' describe whether the processed pixel are simply copied (the pixel in the destination are overwritten -'OVER') or whether they are alpha-blended 'BLEND'. The number in parenthesis describe the position and the size of the affected areas.
This information can be very helpful if your want to find performance problems in your target system. For example, the usage of alpha-blending is much slower can the simple copying of pixel. Assuming a GUI component draws too slow on the target system, then you can extract from these outputs what graphical operations are really performed when the GUI component is drawn. You can analyze this information and verify that there are no superfluous alpha-blending activated for objects which really could be copied instead. By the way, whether a view is alpha-blended or not is controlled by its property 'AlphaBlended'. See 'Mosaic 2.0 User Manual'.
The output text also addresses an important feature of our Graphics Engine. In the very first row of the above example you see how much graphical operations could be eliminated automatically before these are executed. Our Graphics Engine contains some intelligence to collect and analyze drawing operations. In this manner operations, which don't have visual effect are eliminated. Even the above mentioned alpha-blending can be degraded to simple copy operations automatically.
The numbers in the first row describe the graphical operations for the copy (Overwrite) and alpha-blending (Blend) and the respective elimination impact. For example 18(-3) -> 18 operations, 3 eliminated, thus 21 before. The other numbers describe the affected resulting amount of pixel to copy or to blend and the reduction in percent resulting from the elimination algorithms.
Note, sometime the elimination algorithm may replace one big operation by several small operations. For example 18(+4) means that 4 additional operations were added.
This works similarly on the target system. You can e.g. add the macro to your make file and after recompiling the project the graphical operations are output to the 'stdout' stream of the started application.
