Class Display

java.lang.Object
org.freedesktop.wayland.client.Proxy<Void>
org.freedesktop.wayland.client.Display
All Implemented Interfaces:
WaylandObject
Direct Known Subclasses:
WlDisplayProxy

public abstract class Display extends Proxy<Void>
Represents a connection to the compositor and acts as a proxy to the Display singleton object.

A Display object represents a client connection to a Wayland compositor. It is created with either WlDisplayProxy.connect() or WlDisplayProxy.connectToFd(). A connection is terminated using disconnect().

A Display is also used as the Proxy for the Display singleton object on the compositor side.

A Display object handles all the data sent from and to the compositor. When a Proxy marshals a request, it will write its wire representation to the display's write buffer. The data is sent to the compositor when the client calls flush().

Incoming data is handled in two steps: queueing and dispatching. In the queue step, the data coming from the display fd is interpreted and added to a queue. On the dispatch step, the handler for the incoming event set by the client on the corresponding Proxy is called.

A Display has at least one event queue, called the main queue. Clients can create additional event queues with \ref createQueue() and assign Proxy's to it. Events occurring in a particular proxy are always queued in its assigned queue. A client can ensure that a certain assumption, such as holding a lock or running from a given thread, is true when a proxy event handler is called by assigning that proxy to an event queue and making sure that this queue is only dispatched when the assumption holds.

The main queue is dispatched by calling dispatch(). This will dispatch any events queued on the main queue and attempt to read from the display fd if its empty. Events read are then queued on the appropriate queues according to the proxy assignment. Calling that function makes the calling thread the main thread.

A user created queue is dispatched with dispatchQueue(EventQueue). If there are no events to dispatch this function will block. If this is called by the main thread, this will attempt to read data from the display fd and queue any events on the appropriate queues. If calling from any other thread, the function will block until the main thread queues an event on the queue being dispatched.

A real world example of event queue usage is Mesa's implementation of eglSwapBuffers() for the Wayland platform. This function might need to block until a frame callback is received, but dispatching the main queue could cause an event handler on the client to start drawing again. This problem is solved using another event queue, so that only the events handled by the EGL code are dispatched during the block.

This creates a problem where the main thread dispatches a non-main queue, reading all the data from the display fd. If the application would call poll(2) after that it would block, even though there might be events queued on the main queue. Those events should be dispatched with dispatchPending() before flushing and blocking.