Skip to content
Snippets Groups Projects

Gamma correct blending with sRGB

Merged Pekka Paalanen requested to merge pq/weston:mr/color-arch into main
Compare changes
  • Side-by-side
  • Inline
Files
10
  • a8f61a20
    See: #467 (comment 814985)
    
    
    
    This starts building the framework required for implementing color
    management.
    
    The main new interface is struct weston_color_manager. This commit also
    adds a no-op color manager implementation, which is used if no other
    color manager is loaded. This no-op color manager simply provides
    identity color transforms for everything, so that Weston keeps running
    exactly like before.
    
    weston_color_manager interface is incomplete and will be extended later.
    
    Colorspace objects are not introduced in this commit. However, when
    client content colorspace and output colorspace definitions are
    combined, they will produce color transformations from client content to
    output blending space and from output blending space to output space.
    
    This commit introduces a placeholder struct for color transforms,
    weston_color_transform. Objects of this type are expected to be heavy to
    create and store, which is why they are designed to be shared as much as
    possible, ideally making their instances unique. As color transform
    description is intended to be generic in libweston core, renderers and
    backends are expected to derive their own state for each transform
    object as necessary. Creating and storing the derived state maybe be
    expensive as well, more the reason to re-use these objects as much as
    possible. E.g. GL-renderer might upload a 3D LUT into a texture and keep
    the texture around. DRM-backend might create a KMS blob for a LUT and
    keep that around.
    
    As a color transform depends on both the surface and the output, a
    transform object may need to be created for each unique pair of them.
    Therefore color transforms are referenced from weston_paint_node. As
    paint nodes exist for not just surface+output but surface+view+output
    triplets, the code ensures that all paint nodes (having different view)
    for the same surface+output have the same color transform state.
    
    As a special case, if weston_color_transform is NULL, it means identity
    transform. This short-circuits some checks and memory allocations, but
    it does mean we use a separate member on weston_paint_node to know if
    the color transform has been initialized or not.
    
    Color transformations are pre-created at the weston_output
    paint_node_z_order_list creation step. Currently the z order lists
    contain all views globally, which means we populate color transforms we
    may never need, e.g. a view is never shown on a particular output.
    This problem should get fixed naturally when z order lists are
    constructed "pruned" in the future: to contain only those paint nodes
    that actually contribute to the output's image.
    
    As nothing actually supports color transforms yet, both renderers and
    the DRM-backend assert that they only get identity transforms. This
    check has the side-effect that all surface-output pairs actually get a
    weston_surface_color_transform_ref even though it points to NULL
    weston_color_transform.
    
    This design is inspired by Sebastian Wick's Weston color management
    work.
    
    Co-authored-by: default avatarSebastian Wick <sebastian@sebastianwick.net>
    Signed-off-by: default avatarPekka Paalanen <pekka.paalanen@collabora.com>
Loading