Module screen_13::gpu

Contains the heart and soul of Screen 13.

This module does the heavy-lifting work in this library and is made from a number of internal-only modules which support the functionality described here.

Note About Operations

All of the things Render allows are recorded internally using Op implementations which are themselves just containers of graphics API resources and the commands to work on them.

I think this structure is really flexible and clear and might live for a few good versions at least.

NOTE: Op implementations should follow a few rules for sanity:

• Use a Pool instance to acquire new resources
• new(...) -> Self: function initializes with minimum settings
• with_X(&mut self, ...) -> &mut Self: Use the mutable borrow builder pattern for options/extras
• record(&mut self, ...): function does three things:
  1. Initialize final settings/pipelines
  2. Write descriptors
  3. Submit all commands
• submit_X(&self): functions which contain minimal "if" cases and logic; simple calls only.

Note About Rc

Screen 13 currently uses the Rc type in order to synchronize work between various operations.

Unfortunately, this limits Screen 13 resources from being shared across threads. We could simply replace those references with Arc and call it a day (that would work), but I'm not yet sure that's a good pattern, it would introduce unessecery resource synchronization.

I think as the API matures a better solution will become clearer, just not sure which types I want to be Send yet. The driver really could be Sync.

Note About def

Internally Screen 13 uses pre-defined render passes and pipelines to function.

All of these definitions exist in the def module and are great, but inflexible. They only do what I programmed them to do. Lame.

Instead, these definitions should be built and cached at runtime based on the operation which have been recorded. There are follow-on things such as shaders to handle and so I'm not ready for this change yet.

Similiarly, the handling of command buffers and submission queues is currently on a per-operation basis which is very limiting. We should keep running command buffers and only close them when the graph of operations says so.

Modules

clear	Types for clearing textures with a configurable color.
copy	Types for copying textures with configurable source and destination coordinates.
draw	Types for drawing user-specified models and lights onto textures.
encode	Types for encoding textures into the .jpg or .png file formats.
font	Types for writing text onto textures using stylized fonts.
gradient	Types for filling textures with linear and radial gradients.
vertex	Screen 13 offers a number of vertex formats for use loading models.
write	Types for pasting/splatting textures with configurable source and destination transforms.

Structs

BadData	Indicates the provided data was bad.
Bitmap	Holds a decoded 2D image with 1-4 channels.
Cache	An opaque cache of graphics API handles and resources.
Gpu	Allows you to load resources and begin rendering operations.
MeshFilter	A reference to an individual mesh name, which may be shared by multiple meshes.
Model	A drawable collection of individually adressable meshes.
Pose	TODO
Render	A powerful structure which allows you to combine various operations and other render instances to create just about any creative effect.
Texture	A generic structure which can hold an N dimensional GPU texture.

Enums

BlendMode	Specifies a method for combining two images using a mathmatical formula.
MaskMode	Masking is the process of modifying a target image alpha channel using a series of blend-like operations.
MatteMode	Matting blends two images (a into b) based on the features of a matte image.

Type Definitions

BitmapRef	A helpful alias used to share Bitmap instances used with rendering operations.
ModelRef	A helpful alias used to share Model instances used with rendering operations.
Texture2d	A two dimensional rendering result.