Sometimes an application may want direct access to the custom screen's
bitmap to use with low-level graphics library calls.  This may be useful
if the application needs to do custom manipulation of the display but also
needs Intuition functionality.  For instance, an application may want to
use the graphics library primitives to perform double buffering then, when
detecting user input, switch to Intuition control of the screen so that
windows, gadgets and menus may be used to process the user input.  If an
application chooses to combine these techniques, it must take special care
to avoid conflicts with Intuition rendered graphics.  An example of how to
do this is listed in the next section, "advanced screen programming".

Application programs that open custom screens may use the screen's display
memory in any way they choose.  However, this memory is also used by
Intuition for windows and other high level display components on the
screen.  Writing directly to the screen memory, whether through direct
access or through graphics library calls that access the screen's
rastport, is not compatible with many intuition constructs such as windows
and menus.

Techniques such as this require great care and understanding of the Amiga.
If possible, the application should avoid these techniques and only use
standard Intuition display and input processing.  Directly accessing the
screen's bitmap, while possible, is not recommended.  A better way to
access the screen display is through windows.  Windows provide access to
the screen through layers which perform clipping and arbitration between
multiple drawing areas.

Alternatives to writing directly to a screen, such as using a backdrop
window, greatly limit the number of cases where an application must access
screen memory.  The showtitle() function allows the screen's title bar
layer to be positioned in front of or behind any backdrop windows that are
opened on the screen.  Hence, a backdrop window may be created that uses
the entire visible area of the monitor. Application programs that use
existing public screens do not have the same freedom to access the
screen's display memory as they do with custom screens.  in general,
public screens must be shared through the use of windows and menus rather
than directly accessing the screen's display memory.

    Use Direct Access Only On Screens You Own.
    ------------------------------------------
    An application may not steal the bitmap of a screen that it does not
    own.  Stealing the Workbench screen's bitmap, or that of any other
    public screen, is strictly illegal.  accessing the underlying
    graphics structures of a screen may only be done on custom screens
    opened by the application itself.

    Do Not Perform Layers Operations Directly.
    ------------------------------------------
    While layers are not part of the graphics library, it is appropriate
    to mention them here.  Certain types of layers operations are not
    allowed with Intuition.  You may not, for example, call sizelayer()
    on a window (use sizewindow() instead). to access layers library
    features with screens, use Intuition windows!

A custom screen may be created to allow for modification of the screen's
Copper list.  The Copper is the display synchronized co-processor that
handles the actual video display by directly affecting the hardware
registers.  See the Amiga hardware reference manual or the graphics
library chapters for more information on programming the Copper.