Skip to content

Home

Jump to bottom
Timur Gafarov edited this page Feb 21, 2019 · 90 revisions

dlib

dlib is a growing collection of native D language libraries that implement common functionality (read below about our definition of "common"). It is useful for various higher-level projects - such as game engines, rendering pipelines and multimedia applications.

Currently dlib contains the following packages:

  • dlib.core - modules that are widely used by other packages
  • dlib.memory - allocators and memory management functions
  • dlib.container - containers and data structures
  • dlib.filesystem - abstract FS interface and its implementations for Windows and POSIX filesystems
  • dlib.math - linear algebra and numerical analysis (vectors, matrices, quaternions, etc.)
  • dlib.geometry - computational geometry (ray casting, primitives, intersection, etc.)
  • dlib.image - image processing (filters, color correction, FFT, HDRI, graphics formats I/O, support for 8 and 16-bit RGBA buffers and floating point operations)
  • dlib.audio - sound processing (synthesizers, audio formats I/O)
  • dlib.network - networking and web functionality
  • dlib.async - event loop and asynchronous programming capabilities (not available in master branch)
  • dlib.serialization - data serialization (currently includes lightweight XML parser)
  • dlib.coding - data coding and compression algorithms
  • dlib.text - text processing
  • dlib.functional - some functional programming idioms (HOFs, combiners, quantifiers, etc.).

Philosophy behind the project

Why dlib? Read the Rationale.

Memory Management

A large effort is recently being made to lessen garbage collector usage in dlib. The main policy is to make the user responsible for memory allocation, not the library. All necessary internal allocations must avoid using GC and instead should use dlib.core.memory routines or dlib.memory allocators.

This task is almost complete, but there is still a lot of work. The following is a list of modules that support manual memory management:

  • dlib.core is fully GC-free
  • dlib.container is fully GC-free
  • dlib.serialization is fully GC-free
  • dlib.functional is fully GC-free
  • dlib.coding is fully GC-free
  • dlib.text is fully GC-free
  • dlib.math originally avoids GC usage, being designed for real-time application purposes (warning: this is not true for Tensors, which can allocate in certain cases. Use carefully)
  • dlib.geometry is partially GC-free (full code audit haven't been done yet, use with care)
  • dlib.filesystem has GC-free implementations of its interfaces (dlib.filesystem.stdfs)
  • dlib.image is partially GC-free (there are UnmanagedImage class and fully GC-free image decoders, all image filters are also GC-free). See #85 for details
  • dlib.audio has also GC-free implementation of its generic interfaces.

First-place candidates for memory related improvement are dlib.image (parallel image processing, FFT) and dlib.geometry.

Look Manual Memory Management for more details on dlib.core.memory usage.

Issue tracker

On GitHub issue tracker, we use several labels to mark bugs and improvements:

  • Breaking change. This is self-descriptive: an improvement that breaks backward compatibility;
  • Bug. A bug that should be fixed without API change;
  • Enhancement. A non-breaking improvement of existing functionality (e.g. optimization or a new feature);
  • Missing. Appears when existing functionality is removed due to regressions and needs to be rewritten, or when some implementation is not complete;
  • New functionality. Self-descriptive: a new functionality request.
Clone this wiki locally