Cancel all outstanding requests for notification. The function doesn't cancel the submit update requests themselves.

Close the session to the server.

Connect to the server using given number of message slots.

The message signals the client that the buffer associated with the notifier is available for further updates.

For performance reasons, the GCE uses the buffer sent by the client for composition directly rather than composing with a copy of the buffer. This means that, potentially, a client could be rendering to a buffer which is currently being used for composition, leading to artefacts and possible tearing. Depending on whether the surface is single or multi-buffered, there is some difference in behaviour: In the case of single-buffered surfaces, the GCE will not wait for the next submit update and will complete the request after the composition. In case of multi-buffered surfaces, the GCE can postpone with the issuing the notification to the client even after the composition with the specified surface buffer has already happened, and issues the request when the client changes the active buffer, i.e. submits another request for update with different buffer. This will help the GCE to keep the active buffer in a valid state should another composition required.

This notification enables a client to, if desired, be able to perform artefact free rendering using this notification in conjunction with a multi-buffered surface.

Note that since the compositor can delay to issue request complete for multi-buffered surface until the change of the active buffer occurs, the completion of a particular notifier may not relate to the buffer to which it is intuitively associated.

Only the last call of this function before SubmitUpdate command takes place will have effect, i.e. the following call will override the previous one. This request will only be associated with the following single call of the SubmitUpdate.

When a SubmitUpdate has been broadcast to all available screen, i.e. KAllScreens was supplied as a screen number, for multi-buffered surfaces, the notification will be completed when the surface buffer has been released by all displays it is being shown on. For single-buffered surfaces, notification will be completed when all displays have read the buffer once.

Ask the server to notify when the surface buffer which will be specified in the next update request has been displayed for the first time. The notification will also include exact time of the event as it is supplied by the User::FastCounter() . Only the last call of this function before SubmitUpdate command takes place will have effect, i.e. the following call will override the previous one.

Ask the server to notify when the surface buffer which will be specified in the next update request has been displayed for the X times.

Only the last call of this function before SubmitUpdate command takes place will have effect, i.e. the following call will override the previous one.

In case of the global update the notification will always be aligned with the master display. The SUS will send notification to client when the surface has been displayed on a master display for the X times or if there is no master display for that surface. If the master becomes invisible while the request is still in a progress it will be reassigned to the next visible display with highest priority.

This request will only be associated with the following single call of the SubmitUpdate.

Send update message to the server. All notification requests will also be submitted at this stage. This is referring to when notifications are requested before the update request.

The GCE may collapse a few requests into one. If a few requests with different buffer numbers specified for the same surface have been submitted at specific composition cycle, only last such request will have effect.

Clients can send a global submit update which will be broadcast by the SUS to all backends presented in the system. For a global update, to all screens, the pre-defined constant KAllScreens needs to be passed as the screen parameter to SubmitUpdate. Note that once a Client has begun issuing SubmitUpdate with either KAllScreens or a specific screen, then only that type of screen can be used thereafter for that Surface Update Session, i.e. the client cannot have a mix of SubmitUpdate with KAllScreens and specific screens.

Allow to retrieve the version number.