Namespaces | Classes | Enumerations




class  CX::CX_Display
struct  CX::CX_SlidePresenter::FinalSlideFunctionArgs
struct  CX::CX_SlidePresenter::PresentationErrorInfo
struct  CX::CX_SlidePresenter::Configuration
struct  CX::CX_SlidePresenter::SlideTimingInfo
struct  CX::CX_SlidePresenter::Slide
class  CX::CX_SlidePresenter


enum  CX::CX_SlidePresenter::ErrorMode { PROPAGATE_DELAYS }
enum  CX::CX_SlidePresenter::SwappingMode { CX::CX_SlidePresenter::SwappingMode::SINGLE_CORE_BLOCKING_SWAPS, CX::CX_SlidePresenter::SwappingMode::MULTI_CORE }
enum  CX::CX_SlidePresenter::Slide::PresStatus : int {
  CX::CX_SlidePresenter::Slide::PresStatus::NOT_STARTED, CX::CX_SlidePresenter::Slide::PresStatus::RENDERING, CX::CX_SlidePresenter::Slide::PresStatus::SWAP_PENDING, CX::CX_SlidePresenter::Slide::PresStatus::IN_PROGRESS,

Detailed Description

This module is related to creating and presenting visual stimuli.

The CX::Draw namespace contains some more complex drawing functions. However, almost all of the drawing of stimuli is done using openFrameworks functions. A lot of the common functions can be found in ofGraphics.h (, but there are a lot of other ways to draw stimuli with openFrameworks: See the graphics and 3d sections of this page:

Enumeration Type Documentation

The settings in this enum are related to what a CX_SlidePresenter does when it encounters a timing error. Timing errors are probably almost exclusively related to one slide being presented for too long.

The PROPAGATE_DELAYS setting causes the slide presenter to handle these errors by moving the start time of all future stimuli back by the amount of extra time (or frames) used to the erroneous slide. This makes the durations of all future stimuli correct, so that there is only an error in the duration of one slide. If a slide's presentation start time is early, the intended start time is used (i.e. only delays, not early arrivals, are propogated).

Other alternatizes are being developed.

Settings for how the corners are drawn for the lines() function.

The possible presentation statuses of the slide.


The slide is somewhere in the queue awaiting start.


The slide is next in line for presentation and its rendering has started.


The slide is next in line for presentation and its rendering has completed, but it has not been swapped in.


The slide has been swapped in and is now on screen, assuming that the rending completed before the swap.


The slide has been replaced with a new slide.

The method used by the slide presenter to swap stimuli that have been drawn to the back buffer to the front buffer. MULTI_CORE is theoretically the best method, but only really works properly if you have at least a 2 core CPU. It uses a secondary thread to constantly swap the front and back buffers, which allows each frame to be counted. This results in really good synchronization between the copies of data to the back buffer and the swaps of the front and back buffers. In the SINGLE_CORE_BLOCKING_SWAPS mode, after a stimulus has been copied to the front buffer, the next stimulus is immediately drawn to the back buffer. After the correct amount of time minus CX_SlidePresenter::Configuration::preSwapCPUHoggingDuration, the buffers are swapped. The main problem with this mode is that the buffer swapping in this mode blocks in the main thread while waiting for the swap. However, it avoids thread synchronization issues, which is a huge plus.


The slide presenter does bufer swapping in the main thread, blocking briefly during the buffer swap.


The slide presenter does bufer swapping in a secondary thread, which means that there is no blocking in the main thread when buffers are swapping.