benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_/src/include/display-handles.hpp

53 lines
1.2 KiB
C++
Raw Normal View History

keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
/*
Clean-up: remove dummy-player services and interfaces (see #1342) For the [ticket:1221 »Playback Vertical Slice«] one of the next steps will be to define a way to pass buffers from the core to the UI. The `DisplayService` and the `DummyPlayerService` where parts of an early architecture study to see how such a flexible connection between components in different layers can be accomplished. The findings from this prototyping work helped to shape the design of the actual `PlayService`...
2025-05-14 01:32:21 +02:00
DISPLAY-HANDLES.hpp - opaque handle types for playback and display
GPL header whitespace
2010-12-17 23:28:49 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2009, Hermann Vosseler <Ichthyostega@web.de>
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
GPL header whitespace
2010-12-17 23:28:49 +01:00
keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
*/
Doxygen Fixes (#1062) This changeset fixes a huge pile of problems, as indicated in the error log of the Doxygen run after merging all the recent Doxygen improvements unfortunately, auto-linking does still not work at various places. There is no clear indication what might be the problem. Possibly the rather unstable Sqlite support in this Doxygen version is the cause. Anyway, needs to be investigated further.
2017-04-02 04:22:51 +02:00
/** @file display-handles.h
keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
** Opaque handles and similar typedefs used to communicate via the
** lumiera::Display and lumiera::DummyPlayer facade interfaces.
XV-Display: prototype for flexible control of ouput pixel format As an example, the `PixbufDisplayer` needs packed RGB888 data, while the `XvDisplayer` expects YUV (MPEG-style) pixels. The research setup is not well equipped to handle any kind of content or format negotiation; yet for the experimentation, the connections can be wired as !SigC-Signals. After the preceding refactorings, `DummyImageGenerator` can be configured to perform the conversion to YUV only when necessary, and to use the working buffer flexibly. When supplied with packed RGB pixel data, the display in the Gtk::Image is now correct, and also handles layout and scaling appropriately.
2025-05-12 03:43:09 +02:00
**
** @deprecated this is part of prototyping code; as of 5/2025 it is clear
** that we will not use any of these interface schemes (yet something similar)
keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
**
Global-Layer-Renaming: adjust namespace qualification
2018-11-15 23:59:23 +01:00
** @see stage::DisplayService
keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
**
*/
#ifndef LUMIERA_DISPLAY_HANDLES_H
#define LUMIERA_DISPLAY_HANDLES_H
XV-Display: reorganise image-generator code This is a first step towards the ability to produce several different output formats... Refactor the code to separate - the double buffering - the actual image generation, which works in RGB - the conversion routine Furthermore, replace unsigned char by std::byte and introduce std::array and structured binding to avoid many usages of pointers; hopefully this makes the intention of the code clearer. Verified and cross-checked the actual converion logic; in fact this is a conversion to "YUV" as used by MPEG, which in more precise terms is Y'CrCb with Rec.601 colour space and a scan range limitation (16...235) on the Luma component.
2025-05-11 01:18:19 +02:00
#include <cstddef>
keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
XV-Display: reorganise image-generator code This is a first step towards the ability to produce several different output formats... Refactor the code to separate - the double buffering - the actual image generation, which works in RGB - the conversion routine Furthermore, replace unsigned char by std::byte and introduce std::array and structured binding to avoid many usages of pointers; hopefully this makes the intention of the code clearer. Verified and cross-checked the actual converion logic; in fact this is a conversion to "YUV" as used by MPEG, which in more precise terms is Y'CrCb with Rec.601 colour space and a scan range limitation (16...235) on the Luma component.
2025-05-11 01:18:19 +02:00
using DummyFrame = std::byte *;
keep the display handles within a separate header
2009-02-09 05:43:55 +01:00
XV-Display: prototype for flexible control of ouput pixel format As an example, the `PixbufDisplayer` needs packed RGB888 data, while the `XvDisplayer` expects YUV (MPEG-style) pixels. The research setup is not well equipped to handle any kind of content or format negotiation; yet for the experimentation, the connections can be wired as !SigC-Signals. After the preceding refactorings, `DummyImageGenerator` can be configured to perform the conversion to YUV only when necessary, and to use the working buffer flexibly. When supplied with packed RGB pixel data, the display in the Gtk::Image is now correct, and also handles layout and scaling appropriately.
2025-05-12 03:43:09 +02:00
namespace lumiera {
/** Supported Displayer formats */
enum DisplayerInput {
DISPLAY_NONE,
DISPLAY_YUV,
DISPLAY_RGB,
DISPLAY_BGR,
DISPLAY_BGR0,
DISPLAY_RGB16
};
} // namespace lumiera
#endif /*LUMIERA_DISPLAY_HANDLES_H*/
Reference in a new issue Copy permalink