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 some work left. See https://github.com/gecko0307/dlib/issues/158 for status.

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