DOCSEARCHbyAlgolia
Submit Docs

LinaVG 2D Vector Graphics Library

repository·master·Indexed 42 days ago

https://github.com/inanevin/linavg

A low-level 2D vector graphics library for high-performance anti-aliased shape, line, and text rendering. Decoupled from specific rendering engines, it generates optimized buffers for user-defined backends. Supports C++17, FreeType font loading, SDF text, and a wide range of shapes, gradients, and Bezier curves.

Tokens
11.1K
Snippets
22
Records
57
Agent score
54%

What's inside LinaVG

  1. Introduction to GLFW

    master

    GLFW is an open-source, multi-platform library designed for OpenGL, OpenGL ES, and Vulkan application development. It provides a platform-independent API for:

    • Creating windows, contexts, and surfaces
    • Reading input
    • Handling events

    Supported Platforms:

    • Windows: Native support.
    • macOS: Native support.
    • Linux/Unix-like: Native support for both X11 and Wayland.

    GLFW is licensed under the zlib/libpng license.

  2. What is LinaVG and how does it work?

    master

    LinaVG is a 2D vector graphics library for low-level anti-aliased shape, line, and text rendering.

    Key Architectural Concept: LinaVG is not a standalone renderer. It does not manage windows or input, nor does it perform the actual GPU draw calls itself. Instead, it generates optimized buffers based on your draw calls and sends them back to a custom backend that you provide. You are responsible for implementing the rendering logic that consumes these buffers.

    It can be used to build both immediate mode and retained mode GUI applications.

  3. API Stability and Versioning Rules

    master

    When contributing features, adhere to the following API stability rules:

    • Public API changes: Any part of the public API included in a release cannot be changed until the next major version.
    • Backward Compatibility: Code written to the API of one minor release must both compile and run on subsequent minor releases.
    • Feature Addition: Features can be added, and existing parts can sometimes be overloaded (in a general sense, not C++ overloading), provided they maintain compatibility.

  4. Thread-safety in LinaVG

    master

    LinaVG is thread-safe provided that no multiple threads modify the same LinaVG::Drawer object simultaneously.

    Note on Global Functions: Global functions used for loading fonts are currently not thread-safe. You must wrap these calls in a mutex to ensure safe access across threads.

  7. General guidelines for reporting GLFW bugs

    master

    When reporting a bug where GLFW behaves unexpectedly at run-time, follow these steps:

    1. Set an error callback: Use the error callback to identify the cause. If the callback doesn't report an error, the lack of reporting might itself be a bug.

    2. Validate pointers: If the library is crashing or triggering asserts, ensure all object handles and pointers are valid.

    3. Provide a minimal example: A short, self-contained code example is highly valued. If the bug is reproducible using one of the test programs included with GLFW, simply mention that.

    4. Use text, not images: Provide all code, error messages, and logs as plain text so they are searchable and easy for maintainers to copy. Use triple backticks for formatting:

      // Code here

    5. Include platform/version info: Mention your OS, compiler, and the GLFW version (or Git commit ID) you are using.

  8. Report a GLFW window, input, or event bug

    master

    When reporting window, input, or event issues:

    1. Event ordering: Note that the exact ordering of related window events may vary by platform.
    2. Blocking threads: On some platforms, user-initiated window moving or resizing may block the main thread. To keep window contents updated during these operations, set a refresh callback.
    3. Use events tool: Use the events tool (found in tests/events.c in the GLFW source tree) to print all information provided to every GLFW callback.
    4. X11 specific info: If on X11, include your desktop environment (e.g., GNOME, KDE) and window manager (e.g., Openbox, dwm). For keyboard issues, include your input method (e.g., ibus, SCIM).

    When reporting, include:

    • OS and version
    • GLFW release version or Git commit ID
    • Error messages from the error callback
    • The output of the events tool
    • If using a Virtual Machine, include the VM name and version.
    OS and version:
Release or commit:
Error messages:
events output:

  9. Access GLFW documentation and support resources

    master

    For tutorials, guides, and the complete API reference, consult the official GLFW documentation.

    If you encounter issues or have questions, you can use the following community resources:

    To report bugs, use the GLFW issue tracker. When reporting a bug, refer to the contribution guide to ensure you provide all necessary information.

  10. Compile FreeType 2 with PureC compiler

    master

    To compile FreeType 2 as a library using the PureC compiler, you must perform the following three steps:

    1. Rename Source Files: All .c files must start with an uppercase letter. If you have GEMSCRIPT available, you can automate this by dragging the entire FreeType 2 directory onto the FNames.SIC file.
    2. Configure Include Directories: Update the PureC compiler options to include both the standard INCLUDE directory and the freetype2\include directory.
    3. Patch Header Files: You must modify freetype/include/Ft2build.h to include ATARI.H immediately after the build guard definition.
    // Patch for freetype/include/Ft2build.h
#ifndef FT2_BUILD_GENERIC_H_
    #define FT2_BUILD_GENERIC_H_

#include "ATARI.H"

  11. Requirements for contributing a feature

    master

    Before implementing a feature, check for existing open issues or ongoing development in experimental branches. You must have the intellectual property rights to any code contributed.

    A complete feature contribution should include:

    • A change log entry in README.md listing all new symbols.
    • A news page entry briefly describing the feature.
    • Guide documentation with minimal examples in the relevant guide.
    • Reference documentation with all applicable tags.
    • Cross-references and mentions in appropriate places.
    • Credits entries for all authors.

    Platform and Testing Requirements:

    • Platform-specific code: If the feature requires platform-specific code, you must add stubs for the new platform function to all supported and experimental platforms.
    • New Callbacks: Support must be added to tests/event.c.
    • New Monitor Properties: Support must be added to tests/monitor.c.
    • New Graphics Options/Extensions (OpenGL, OpenGL ES, Vulkan): Support must be added to tests/glfwinfo.c and the behavior when the extension is missing must be documented in docs/compat.dox.

  12. Report a GLFW monitor or video mode bug

    master

    When reporting monitor or video mode issues:

    1. Headless systems: Note that on some platforms, headless systems may report no monitors, causing glfwGetPrimaryMonitor to return NULL.
    2. Video mode filtering: GLFW only reports video modes approved by the OS. This is intended behavior.
    3. Use monitors tool: Use the monitors tool (found in tests/monitors.c in the GLFW source tree) to see what information GLFW detects.

    When reporting, include:

    • OS and version
    • GLFW release version or Git commit ID
    • Error messages from the error callback
    • The output of the monitors tool
    • If using a Virtual Machine, include the VM name and version.
    OS and version:
Release or commit:
Error messages:
monitors output: