65
8.5.3.3.1 Colour support
8.5.3.3.1.1 GDI, FBSERV and BITGDI
The
TDisplayMode
enum has been enhanced to include
EColor4k
display mode so that
EPOC now supports 2, 4, 16 and 256-level greyscale displays, and 16, 256, 4k, 64k and 16
million colour displays. The font and bitmap server FBSERV has been enhanced to support
bitmaps in these display modes, the BITGDI has been enhanced to draw to them, and the
bmconv
tool has been enhanced to produce bitmaps in them all. Given a
TDisplayMode
, the
TDisplayModeUtils
class returns whether a display mode is colour or not, and how many
colours/grey values it supports.
EPOC constrains the physical colours supported by its colour display modes as follows:
•
16-colour displays use the EGA colour set: black, white, and then both light and dark
versions of grey, red, green, blue, cyan, magenta and yellow
•
256-colour displays support 216 colours made up of 6x6x6 RGB values, each containing
all possible multiples of 51 for R,G,B values. Additionally, all remaining 10 shades of
pure red, green, blue and grey are represented, by adding all remaining multiples of 17.
This use of 256 colours is sometimes known as the Netscape colour cube.
•
4096-colour displays effectively support RGB values with 4 bits per primary colour
•
64k-colour displays effectively support RGB values with 5 bits allocated to red, 6 to
green and 5 to blue
•
16M-colour displays support true colour with 8 bits allocated to each primary colour
This means that, in each display mode, a unique index can represent the physical colours
supported and can be mapped onto a full RGB value. The
TRgb
class has been augmented to
include this mapping function and also a mapping function from RGB to the nearest physical
colour. With this design, EPOC does not need to support hardware palettes with their associated
hardware overheads, programming complexities, and occasionally strange visual effects.
8.5.3.3.1.2 Window server
The window server has been enhanced to support the requirements of machines with colour
displays with different modes, windows with different display requirements, and backwards
compatibility.
A
wsini.ini
file specification indicates to the window server the default display mode to use
for new windows: this need not be specified on machines which support only one display mode,
but most OEMs would wish to specify it on hardware with multiple display modes. On the PC-
based emulator, it should be chosen to emulate the required hardware.
Windows are given a default display mode on creation, which may be altered throughout the
window’s lifetime (except backed-up windows: their display mode is specified on creation and
cannot be changed). The window server optimizes the display mode in use to be the least
demanding (in terms of memory and power) for all of the windows currently displayed.
When using off-screen bitmaps, best performance is obtained by creating the bitmap in the same
mode as the window to which it will eventually be blitted. You should use the
RWindowBase::DisplayMode()
function to determine this. Legacy code, written
without this in mind, will function correctly, albeit slightly slower because of bitmap format
conversions during blitting.
8.5.3.3.1.3 EIKON
Prior to EPOC R5, EIKON and applications used hard-coded greyscale values for all their
drawing. This is still appropriate for some purposes (eg, rendering pictures), but for UI element
drawing colour creates much more flexibility, and it is better to write drawing code in terms of
logical colours
(eg dialog title bar background) rather than RGB colours (eg light grey, or dark
cyan). EIKON supports this requirement with a kind of palette known as a
colour list
, to support
this. The colour list
•
supports logical-to-RGB colour mappings loaded from resource files or specified
programmatically
