Overview
FM4, S6E2DH/S6E2DF/S6E2D5/S6E2D3 Series, 32-Bit Microcontroller, Graphic Driver User Manual, Doc. No. 002-04387 Rev. *A
31
4.10.5 Index images for blit operations
Blit operations like blending a traffic sign to a target buffer can be proceeded like operations with standard RGB(A)
images because the surface contains the required information.
Note:
The following restrictions exist for indexed images:
Surfaces describing an indexed image cannot be used as STORE buffer.
It is not possible to use indexed images as DST and SOURCE surface for one blit.
Indexed images cannot be scaled or rotated.
4.10.6 Index images for the windows
The display hardware can directly show indexed images. In this case the application needs to request the
MML_GDC_DISP_FEATURE_INDEX_COLOR feature while opening the window.
However, there are some restrictions if the window also uses the MML_GDC_DISP_FEATURE_MULTI_LAYER
feature:
All windows with the same layer ID must use the same index width (red channel bit width) if they show indexed
images.
One layer with up to 8 sub-layer-windows can only store 256 palette entries. So if the index width is 8 for this
layer all windows will use the same palette.
If the index width is smaller than 8 than the palette is split in 2 or more parts and the sub-layer-windows can
partly use different palettes. The following rule is implemented in hardware: the upper bits of the 8-bit look-up
index are then filled up with the upper bits of the sub-layer index. Example: when a 6-bit color index value is
used (= 64 colors), 4 palettes can be stored, each shared by 2 layers (layer 0 and 1 use palette entries 0..63,
layers 2 and 3 use 64..127 and so on).
Note:
The driver does not check this rule. If the application binds surfaces with different palettes to windows sharing the
same hardware palette a wrong image will be the result.
Like other settings also palettes are shadowed. It means you can commit the binding of a new indexed image
surface with a new palette while an old one is still visible. If sub-layer-windows share the same palette it is
recommended to hide all windows before the new palette becomes active.
Notes:
Unfortunately the hardware shadow handling for palettes is in some cases not as expected: Each update request in
a window group with the same palette triggers the palette swap. For instance
2 (or more) sub-windows address the same palette part (e.g., if index width is 8 all sub-windows use the
same palette).
Only one window uses the palette.
The commits for all windows without palette may also trigger the palette swap. (for example with index width
8 it means that each commit of a window with the same layer id can trigger the swap and the window with
the indexed surface will sometimes show the correct and sometimes wrong colors.)
To avoid this problem the application must commit a surface with a new palette twice. The two times commits
ensure that the shadow palette is filled with the correct color table. In practice the application may call 2 times
mmlGdcDispWinCommit() directly. In this case the CPU will be blocked until the first commit is taken over by the
hardware (when a new display frame is started). If blocking is not acceptable the application must take care that the
next render loop calls the mmlGdcDispWinCommit() for this window. As soon as the application changes properties
for this window (e.g., change global transparency for fading) the mmlGdcDispWinCommit() call is anyway
necessary.
