Changing color depth on the fly ?

[Glynn Clements]

Vedran Rodic wrote:

> I would beg to differ, but that will have to wait my example
> implementation of depth changing for the randr interface (if I ever
> get to it). Changing of colour depths on the fly is important for
> embedded machines, and possibly in the future for devices that will
> support more than 8 bits for colour components.
> 
> How this should work is pretty much described in the original randr
> paper from Keith. I guess it was never implemented because other
> things had bigger priority.

Or possibly because it creates a massive incompatibility with existing
code. Once a program queries the depth and format of a drawable, that
information is assumed to remain valid for the lifetime of the client.

At present, there isn't even any mechanism by which a client could be
notified of a change of depth. Even if there was, many existing
clients would have to be modified to allow for this situation.

When this feature was originally added to Windows, you would get a
dialog warning you that it could have undesirable side effects, and
offering you a three-way choice to either do nothing, reboot (with the
change taking effect afterwards), or to change depth immediately (at
the risk of crashing programs which didn't allow for the screen depth
suddenly changing).

And this is considering that Windows clients have less need (than do X
clients) to know the pixel format, as (unlike X) Windows' GDI does
dynamic colour remapping.

-- 
Glynn Clements <glynn at gclements.plus.com>