screen basics

Screen is a compositing windowing system. It is able to combine multiple content sources together into a single image.

Two types of composition:

1. Hardware composition: composes all visible(enabled) pipelines at display time.
   • In order to use this,
     • You need specify a pipeline for your window: use screen_set_window_property_iv().
     • use screen_set_window_property_iv() to set the SCREEN_USAGE_OVERLAY bit of your SCREEN_PROPERTY_USAGE window property.
   • The window is considered autonomous as no composition was performed (on the buffers, which belong to this window) by the composition manager.
   • For a window to be displayed autonomously on a pipeline, this window buffer’s format must be supported by its associated pipeline.
2. Composition manager: Composes multiple window buffers (belong to multiple windows) into a single buffer, which is associated to a pipeline.
   • The single buffer is called /composite buffer/ screen framebuffer.
   • Used when your platform doesn’t have hardware capabilities to support a sufficient number of pipelines to compose a number of required elements, or to support a particular behavior,
   • One pipeline is involved (you don’t specify the pipeline number and OVERLAY usage).
   • Requires processing power of CPU and/or GPU to compose buffers

Note:Pipeline (in display controller) equals to layer (in composition manager), which is indexed by EGL level of app.

Pipeline ordering (Hardware property) and z-ordering (for windows)

• Pipeline ordering and the z-ordering of windows on a layer are applied independently of each other.
• Pipeline ordering takes precedence over z-ordering operations in Screen. Screen does not have control over the ordering of hardware pipelines. Screen windows are always arranged in the z-order that is specified by the application.
• If your application manually assigns pipelines, you must ensure that the z-order values make sense with regard to the pipeline order of the target hardware. For example, if you assign a high z-order value to a window (meaning it is to be placed in the foreground), then you must make a corresponding assignment of this window to a top layer pipeline. Otherwise the result may not be what you expect, regardless of the z-order value.

Window: a window represents the fundamental drawing surface.

• An application needs use multiple windows when content comes from different sources, when one or more parts of the application must be updated independently from others, or when the application tries to target multiple displays.
• To use the same window, the content must have the same FORMAT, DISPLAY, BRIGHTNESS, PIPELINE, POSITION, SIZE, SOURCE_POSITION, SOURCE_SIZE, TRANSPARENCY, ZORDER, etc.

Pixmap: A pixmap is similar to a bitmap except that it can have multiple bits per pixel (a measurement of the depth of the pixmap) that store the intensity or color component values. Bitmaps, by contrast, have a depth of one bit per pixel.

• You can draw directly onto a pixmap surface, outside the viewable area, and then copy the pixmap to a buffer later on.

Note: Multiple buffers can be associated with a window whereas only one buffer can be associated with a pixmap.

sleep & delay function (2)

To let the thread to suspend the exact amount of time, without being affected by thread scheduling, we can use nanospin().

int nanospin( const struct timespec *when );

 

The nanospin() function occupies the CPU for the amount of time specified by the argument when without blocking the calling thread. (The thread isn’t taken off the ready list.) The function is essentially a do…while loop.

The first time you call nanospin(), the C library invokes nanospin_calibrate() with an argument of 0 (interrupts enabled), if you haven’t already called it.

int nanospin_ns( unsigned long nsec );

The nanospin_ns() function busy-waits for the number of nanoseconds specified in nsec, without blocking the calling thread.

void nanospin_count( unsigned long count );

The nanospin_count() function busy-waits for the number of iterations specified in count. Use nanospin_ns_to_count() to turn a number of nanoseconds into an iteration count suitable for nanospin_count().

sleep & delay functions (1)

Quoted from QNX document.

— delay(unsigned int duration) suspends the calling thread for duration milliseconds.

— sleep(unsigned int seconds) function suspends the calling thread until the number of realtime seconds specified by the seconds argument have elapsed, or the thread receives a signal whose action is either to terminate the process or to call a signal handler.

both delay() and sleep() returns either 0 or the number of unslept time if interrupt by a signal.

— usleep(useconds_t useconds) function suspends the calling thread until useconds microseconds of realtime have elapsed, or until a signal that isn’t ignored is received.

— nanosleep( const struct timespec* rqtp, struct timespec* rmtp )  function causes the calling thread to be suspended from execution until either:

• The time interval specified by the rqtp argument has elapsed

  Or

• A signal is delivered to the thread, and the signal’s action is to invoke a signal-catching function or terminate the process.

usleep() and nanosleep()  returns either 0 (success) or -1 (an error occured)

 

Note:

With all the functions above, the suspension time may be greater than the requested amount, due to the nature of time measurement (see the Tick, Tock: Understanding the Neutrino Microkernel’s Concept of Time chapter of the QNX Neutrino Programmer’s Guide), or due to the scheduling of other, higher priority threads by the system.