Skip to content

dlib 2.0

Jump to bottom
Timur Gafarov edited this page Feb 8, 2023 · 64 revisions

dlib 2.0 is the successor of dlib 1.x. It will have more thoroughly thought out architecture and more lower-level features.

Premises

  • dlib 1.x historically went its own unique way without considering the ecosystem. Now D community is embracing @nogc and betterC. New libraries should be usable together, and so they should be based on the same constraints and idioms.
  • dlib 1.x aims to be backward-compatible as much as possible. As a result, too many trade-offs accumulated over time while adding new features, and the code became not very consistent. GC-free and GC-dependent functions are mixed together.
  • dlib 1.x requires too much understanding of its internals from user. There are parts that "just work", but some parts often work in counter-intuitive way, or require some arcane boilerplate code which make them not very pleasant to use (for examle, dlib.filesystem.stdfs or dlib.network).

Principles

dlib 2.0 will address most of the drawbacks of classic dlib, including:

  • Incompatibility with @nogc and betterC
  • Dependency on Phobos. dlib will implement the most basic functionality in platform-independent manner, and only use Phobos when there's no other choise
  • Mixed GC-dependent and GC-free code. There will be separate layers for betterC, @nogc and GC-dependent functionality.

Because classes require druntime and significant background work implicitly added by the compiler, all OOP features should also be separated. The library will consist of several layers, from lowest possible level (betterC) to runtime-dependent, where each layer is based on previous.

API structure

dlib 2.0 will consist of several API layers:

  1. dcore - betterC-compliant low-level procedural API, a minimal standard library replacement. Completely standalone. Possible support for bare metal/WebAssembly/ARM.
    • Dynamic memory allocation (if available for target platform)
    • Standard I/O, pipelines (if available for target platform)
    • Basic filesystem (if available for target platform)
    • Portable math
    • Linear algebra
    • Basic containers: dynamic array, dictionary, string
  2. dlib2 - @nogc object-oriented API with high-level features. Serves as an abstract interface for system APIs. Will support at least Unix and Windows. Based on dcore and @nogc parts of Phobos.
    • Streams
    • Multithreading
    • Abstract filesystem
    • Image processing
    • Audio processing
    • JSON
    • Networking
  3. dlib - classic dlib 0.x/1.x API. As much functionality as possible will go to dcore and dlib2, this API will be only for backwards compatibility. Based on dcore, dlib2 and Phobos.
  4. dlib3 - a home for experimental/optional features.
    • New image decoder based on stb which is faster than dlib's native decoders. Ideally stb_image should be ported to D for better portability and ease of use
    • GPU acceleration for image filters via OpenCL
    • Real-time 2D canvas with vector shapes and text (based on Vulkan or, better, WebGPU).

Memory Management

TODO

Clone this wiki locally