Trash. Visuals

Visuals API

This document describes the full specification of the visuals API. This layer allows to create visual objects that contain a bunch of similar primitives (e.g. set of lines, set of points, set of triangles...). The rationale is that multiple primitives of the same type can be rendered very efficiently with a single OpenGL command.

Overview

Visual classes are divided into two categories:

• low-level visuals are responsible only for translating data into graphics. This means taking care of most OpenGL calls, preparing data and sending it to the GPU, supporting user-defined transformations, and supporting a range of optimization modes. These may be used in the absence of a scenegraph. For example: lines, triangles, particles, images.
• high-level visuals are scenegraph objects that generally make use of one or more low-level visuals (although they are permitted to make their own OpenGL calls directly, if desired). High-level visuals provide more data management and analysis than low-level. They provide a more 'forgiving' API--whereas low-level visuals may require a particular data format, high-level visuals 'just work' with any reasonable data. For example: surface plots, histograms, spectrograms, combined line+marker+errorbar plots, etc.

[Should one of these categories be given a different name entirely?]

Transformations

As much as possible, all visuals should support arbitrary, user-defined coordinate transformations. These may come in the form of vertex shaders or python functions (generally, both should be available).

Optimization

Visuals are primarily concerned with the difficult task of getting data on-screen with a variety of constraints: visual appearance, performance (frame rate for drawing static data already residing in VRAM), latency (time duration from arrival of new data to display on-screen), and memory usage (both RAM and VRAM). In general, all of these constraints interact. If we optimize for best visual appearance, we are usually forced to give up performance, latency, and memory efficiency. If we optimize for latency, we may need to sacrifice appearance, performance, and memory usage, and so on.

Thus, we have two architectural possibilities to choose from:

• Each Visual implements multiple rendering pipelines and selects the best one based on some criteria.
• Each low-level Visual implements a single rendering pipeline, and it is the job of high-level Visuals (or the user) to decide which low-level Visuals to select from.

..and in either case, pipelines may be selected based on a few different criteria:

• user input (eg, user requests highest possible quality or lowest possible latency)
• data heuristics (we guess which method to use based on the properties of the data)
• rendering heuristics (we monitor performance and adjust as needed to keep the interface responsive)

Interface

Examples

Example 1: ...

Example 2: ...

Full specification