Khronos Frequently Asked Questions

For Implementors

Why do the Composition and Display APIs have similar features for on-screen composition?

Both of the APIs can perform similar operations to the inputs and output to a screen. By having overlapping features it is not neccessary to implement both APIs, but choose the most suitable one. A WFD device is intended to expose the limitations of the underlying HW. There may be for example a limited number of pipelines in the display controller HW. A WFC device can always compose to memory, so it can overcome limitations by outputting intermediate results to memory and using them again as input.

When would it make sense for a WFD implementation to expose no pipelines?

The expected case for zero exposed pipelines is when the same manufacturer provides a WFD implementation as well as other graphics composition APIs, for instance WFC, such that exposing the WFD pipelines would be unnecessary since other more capable, less limited, composition graphics APIs exist. Given this case, the WFD implementation would be used to manage and configure the display hardware, but not be involved in the composition of displayed content.

What is the purpose of the "attribList" parameter of the WFC or WFD "create" functions?

The creation attribute list parameters are expected to be one of the primary means of extending the functionality of the APIs. At the moment most of the create functions do not have any defined attributes that can be passed in, but providing this feature allows for extensions to be written for these APIs in a fairly clean manner.

Why are the WFC & WFD extension query functions different than other Khronos APIs?

The OpenWF extension query functions (GetStrings, IsExtensionSupported) were developed per recommendations from several of the other Khronos working groups. Members of these other working groups have found that the previously defined methods are more cumbersome then expected, so suggestions were made to address this. It is expected that other Khronos APIs will, over time, move towards this new style of extension functions.

What is the point of allowing creation of more than one composition device with the same device ID?

As the multiple devices created from the same ID do not share any state, it is possible to create a device – context pair for each screen supported by the device and have a separate error state for each screen/ context.

How can a WFC implementation access the screen using WFD API?

If a WFC implementation tries to access the screen using the public WFD API, it is likely to result in an error or preventing other clients from using WFD. The reason is that WFD API allows only one device instance created per device ID. It is recommended that interaction between the two APIs is handled using a propriety solution.