The lower layer of the Shiny API is responsible for creating a render context for each platform supported. It is also responsible for handling input from keyboard and other peripheral devices. The main concepts of the graphical presentation are Buffers, Textures, and Windows:

• Buffer: A buffer refers to an array of pixel data in memory. This could be a loaded image, a canvas for drawing, or any other graphical data that needs to be presented within an application.
• Texture: A texture is a handle to a snapshot of graphical state that's ready to be rendered. It will not be accessible to the application. A texture may be rendered immediately (such as the current widget state) or stored and rendered many times in the future (such as an image).
• Window: A window is the location of an application's graphical output. Textures are rendered to the window after certain transformations (determined by the driver) have been applied.

In normal application flow, the code of a graphical user interface will update a widget or layout state—resulting in a buffer's contents being updated. This buffer will then be uploaded to a texture in preparation for being drawn by the driver. The texture will then be rendered to the application window, potentially through transformations within the driver or the underlying platform's graphical implementation. If you are familiar with how OpenGL works, then the processes will seem quite familiar—this is no coincidence, as the approach is well-proven and one of the Shiny drivers uses the OpenGL APIs. For most application developers, the existence of textures will not be visible or important, but it can help to consider the process when optimizing your code.

The driver also handles user interactions, encapsulating them as mouse.Event and key.Event structures (defined in x/mobile/event). A widget.Widget can register to receive these events, using a filter that will determine which are relevant to that object, and mark them as handled. Alternatively, an application could access the event queue directly from screen.Window, where calling NextEvent() would wait until another event occurs. An application that takes this approach should be aware of the vast number of events that can be generated by Shiny (see Example in the Getting started section later in this chapter). When working with events, the Shiny project includes a powerful gesture package, that enables you to filter on gesture.Event, which describes more intent-based information than lower-level data. Helpful event types include gesture.TypeDrag, gesture.TypeIsLongPress, and gesture.TypeIsDoublePress (the event type is accessible through Event.Type on gesture events).