Graph attribute unified control system and method and medium
The unified control system for graphics attributes solves the problems of fragmented control and poor compatibility of graphics applications, realizes unified management and security control of graphics applications in the system, adapts to various business scenarios, reduces maintenance costs and improves display controllability.
Patent Information
- Application Number
- CN202511773163.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-28
- Publication Date
- 2026-03-20
AI Technical Summary
In current operating systems, the control of graphical applications is decentralized, security risks are high, and compatibility is poor, resulting in complex internal design and difficulty in unified management and maintenance.
A unified control system for graphic attributes is provided, including a graphic attribute configuration management module, a graphic attribute control interface module, and a graphic service/protocol registration and monitoring module. It achieves centralized and unified management and control of the layer attributes of all graphic applications through configuration files and inter-process communication mechanisms.
It achieves unified management of graphics applications, reduces code complexity and maintenance costs, adapts to various business scenarios, is compatible with third-party applications, avoids unexpected events of unknown layers, and has strong display controllability.
Smart Images
Figure CN121704945A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer graphics processing, in particular to a graphics attribute unified control system, method and medium. BACKGROUND
[0002] In the current operating system (such as QNX, Linux), the graphics application usually requests the graphics service from the system graphics service process (such as QNX Screen, Wayland compositor) in the form of a client. Each application program is an independent client, and the control of its own graphics (such as creation, rendering, setting position, transparency, etc.) is also limited to the application itself.
[0003] This architecture has the following technical problems:
[0004] 1. Control is scattered: the timing from system startup to multiple application interface display (such as startup animation, graphics application A, graphics application B, etc.) varies according to the specific needs of the business. However, the control of the application on the graphics is closed, and once the external needs to control the graphics change or attributes of the application, it can only be controlled by the application exposed interface provided to the outside or the application itself responds to the conditions to control the layer. However, each application provides its own graphics-related control method, which makes the internal design of the application more complex, and the graphics-related application will have repeated design and implementation, which is not conducive to iteration and maintenance.
[0005] 2. Security risks: the external control interface provided by each application may introduce security risks.
[0006] 3. Poor compatibility: when a third-party graphics application is added, the functional compatibility is hindered, and it is difficult to achieve unified display control.
[0007] Therefore, there is an urgent need in the art for a technical solution that can uniformly, safely and efficiently control the layer attributes of all graphics applications in the system. SUMMARY
[0008] The present application aims to solve the above technical problems and provides a graphics attribute unified control system and method to realize centralized and unified control of the layer attributes of all graphics applications.
[0009] The present application is implemented by the following technical solutions:
[0010] A graphics attribute unified control system, comprising:
[0011] a graphics attribute configuration management module for loading and caching a predefined graphics attribute configuration file to establish and maintain a mapping relationship between a layer identifier and a graphics attribute;
[0012] a graphic attribute control interface module, configured to receive a graphic control instruction from outside;
[0013] a graphic service / protocol registration and monitoring module, configured to register and monitor a system graphic service to obtain a system layer event;
[0014] The graphic attribute configuration management module is configured to:
[0015] receive the graphic control instruction from the graphic attribute control interface module and the system layer event from the graphic service / protocol registration and monitoring module;
[0016] compare a layer attribute associated with the received graphic control instruction or system layer event based on the mapping relationship;
[0017] The graphic service / protocol registration and monitoring module is configured to, in response to a comparison result of the graphic attribute configuration management module, call a system graphic service interface setting instruction or an event description layer attribute to a system.
[0018] As an optimization, after the graphic attribute configuration management module compares the received graphic control instruction, if the comparison result indicates that the layer exists and the attributes are inconsistent, the graphic attribute configuration management module performs:
[0019] updates the corresponding attribute value in the mapping relationship;
[0020] sends an attribute setting instruction to the graphic service / protocol registration and monitoring module.
[0021] As an optimization, the graphic attribute control interface module is configured to forward the received graphic control instruction to the graphic attribute configuration management module, and receive a comparison result returned by the graphic attribute configuration management module, if the comparison result is that the layer exists and the attributes are inconsistent, trigger or assist the graphic attribute configuration management module to send the attribute setting instruction to the graphic service / protocol registration and monitoring module, so as to call the system graphic service interface setting instruction corresponding layer attribute to the system.
[0022] As an optimization, after the graphic attribute configuration management module compares the received system layer event, if the comparison result indicates that the layer identifier does not exist in the mapping relationship, the graphic attribute configuration management module performs:
[0023] adds the layer identifier and the attribute of the layer identifier to the mapping relationship, and sets the visibility attribute of the layer identifier to invisible;
[0024] sends an attribute setting instruction to the graphic service / protocol registration and monitoring module to set the layer invisible attribute to the system.
[0025] As optimization, the graphic attribute configuration management module compares the received system layer event, and if the comparison result shows that the layer exists but the attribute is inconsistent, the following is executed:
[0026] With the cached attribute value in the mapping relationship as a reference, an attribute setting instruction is sent to the graphic service / protocol registration and listening module, so that the layer attribute of the event is refreshed to the cached value.
[0027] As optimization, the graphic attribute configuration file is a JSON format file; and the mapping relationship is cached through an unordered mapping container of a C++ standard library.
[0028] As optimization, the process intercommunication mode adopted by the graphic attribute control interface module for receiving external instructions includes at least one of a SOME / IP protocol or a PPS (QNX Persistent Publish / Subscribe) mechanism.
[0029] As optimization, the system graphic service is a Screen graphic service of a QNX operating system, or an input layer management service based on a Wayland protocol under a Linux operating system.
[0030] The application further discloses a graphic attribute unified control method, which is executed by the graphic attribute unified control system.
[0031] The mapping relationship is established and maintained by the graphic attribute configuration management module;
[0032] External graphic control instructions are received by the graphic attribute control interface module, and system layer events are listened to by the graphic service / protocol registration and listening module;
[0033] The layer attribute associated with the received instruction or event is compared by the graphic attribute configuration management module;
[0034] The layer attribute described by the instruction or event is set to the system by the graphic service / protocol registration and listening module in response to the comparison result.
[0035] The application further discloses a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to realize the graphic attribute unified control method.
[0036] Compared with the prior art, the application has the following advantages and beneficial effects:
[0037] In the system, each graphic application does not need to care about the attribute control of the respective graphic, and does not need to provide an external control interface, so that the code complexity and maintenance cost are reduced.
[0038] The application can adapt to various business scenarios and realize unified control of graphic display timing through the configuration file and external interface.
[0039] The application is fully compatible with third-party graphic applications and avoids unknown layer emergencies through central authority control, and has strong controllability in display.
[0040] The method of the application can be implanted in the existing system environment and does not need to adapt to graphic-related applications. BRIEF DESCRIPTION OF DRAWINGS
[0041] The drawings described herein are used to provide further understanding of the embodiments of the application, constitute a part of the application, and do not constitute a limitation on the embodiments of the application. In the drawings:
[0042] Figure 1 is the overall schematic diagram of the core method flow of the application.
[0043] Figure 2 is the detailed flow structure diagram of each part / each step of the system of the application.
[0044] Figure 3 is the module composition and data flow schematic diagram of a preferred embodiment of the application.
[0045] Figure 4 is a JSON format example diagram of the graphic attribute configuration file of the application.
[0046] Figure 5 is the start timing diagram of the system module of the application.
[0047] Figure 6 is the processing timing diagram of the application control layer event (external control flow).
[0048] Figure 7 is the processing timing diagram of the system layer event (internal event flow). DETAILED DESCRIPTION
[0049] In order to make the purpose, technical scheme and advantages of the application more clear and obvious, the application will be further described in detail below in combination with embodiments and drawings. The illustrative embodiments of the application and the description thereof are only used to explain the application and do not limit the application.
[0050] The basic idea of the application is to meet the system graphic event listening and control ability through the function interface provided by the system-based graphic subsystem (or display server protocol). At the same time, a unified graphic control interface is provided to control the corresponding layer attributes with layer name or process name as the key.
[0051] I. System architecture overview
[0052] See Figures 1 to 3 This system mainly comprises three core modules: graphics attribute configuration management, graphics attribute control interface, and graphics service / protocol registration and listening. These modules work together to ultimately achieve unified control of graphics attributes. Overall, using a configuration file (JSON) as a static basis, the graphics attribute configuration management module makes unified decisions to synchronize system layers with external control requirements.
[0053] II. Module Details
[0054] 1. Graphic Attribute Configuration Management Module
[0055] Configuration Loading and Caching: This module is invoked and executed by the main process. Upon startup, it first loads a predefined graphical property configuration file from the file system. This graphical property configuration file is preferably in JSON format (e.g., ...). Figure 4 (as shown), because it is versatile and easy to maintain.
[0056] The module retrieves layer information data from the graphics attribute configuration file. This data defines the layer name (e.g., bg_refresh) and its corresponding attributes (e.g., screenid, layerid, width, height, posX, posY, zorder, visibility, opacity, etc.). After loading, the module uses the unordered map container (std::unordered_map) from the C++ standard library to cache the configuration in memory, establishing a mapping relationship with the layer identifier (name) as the key and its complete set of attributes as the value. This mapping relationship serves as the sole benchmark for attribute comparison by the system.
[0057] Attribute comparison and decision: This module acts as the system's decision-making brain. It receives input from the other two modules, performs table lookups and comparisons, and finally returns the corresponding comparison status to drive subsequent operations.
[0058] A. Processing external control commands: When a graphics control command is received from the graphics attribute control interface module, this module compares the target attribute in the graphics control command with the base attribute of the corresponding layer in the cache (that is, the external module calls the graphics output control interface to input attribute parameters, the attribute control interface parses the attribute parameters according to the interface protocol, and passes them to the graphics attribute configuration management).
[0059] a. If the layer attribute does not exist in the cache: add the input attribute parameters to the cache and return a state that the layer does not exist.
[0060] b. If the layer attribute exists and differs from the input attribute: then update the corresponding attribute value in the mapping relationship (i.e. update the cache with the new input attribute to make it the new baseline) and return the attribute difference status.
[0061] c. If the layer attributes exist but the attributes are the same: then there is no need to change the cached attribute data, and the attribute difference status is returned.
[0062] B. Handling System Layer Events: Upon receiving a system event reported by the Graphics Service / Protocol Registration and Listening Module, this module compares the current system attributes carried in the event with the baseline attributes in the cache.
[0063] a. If the layer identifier does not exist in the mapping: add this new layer identifier and its attributes to the mapping, and set the visibility attribute of this layer to invisible (this is a forced control strategy), then return to the state that the layer does not exist.
[0064] b. If the layer attributes exist and differ from the input attributes: then based on the existing cached attributes, no attribute updates will be made, and the attribute difference status will be returned.
[0065] c. If the layer attributes exist but are indistinguishable: no processing is required, and the attribute indistinguishability status is returned.
[0066] Decision output: The status generated by the above comparison process (layer does not exist, attributes differ, attributes do not differ) will be returned to the input source module (graphic attribute control interface module or graphics service / protocol registration and listening module) as the basis for whether and how to execute subsequent operations.
[0067] Specifically, when processing external control commands, if the comparison returns a state where the attributes differ, the input attributes need to be set to the corresponding system layer for immediate effect; otherwise, the interface call is terminated. When processing system layer events, if there is a difference in the attribute comparison or the attribute does not exist, the layer needs to be refreshed with the cached attributes; otherwise, no processing is performed.
[0068] 2. Graphical Attribute Control Interface Module
[0069] This module serves as the entry point for providing unified control capabilities to the outside world. Its external interfaces use key-value pairs, mapping attribute names to attribute values, for parameter passing.
[0070] Inter-process communication methods include SOME / IP and PPS (QNX Persistent Publish / Subscribe), which can be compatible with multiple inter-process communication methods to adapt to more system operating environments.
[0071] When the module is working, it receives graphics control commands from the outside, such as layer name, visibility, size, position, etc., and parses the commands.
[0072] In a preferred implementation, the module forwards the received graphics control command to the graphics attribute configuration management module and receives the comparison result returned by it. If the comparison result indicates that the layer exists but the attributes are inconsistent, the module can trigger or assist the graphics attribute configuration management module to send the attribute setting command to the graphics service / protocol registration and listening module to call the system graphics service interface to set the layer attribute corresponding to the graphics control command in the system; if the graphics attribute configuration management returns a state that the layer attribute does not exist (not configured) or the input attribute is consistent with the configured attribute, the call ends and returns directly without outputting anything.
[0073] 3. Graphics service / protocol registration and monitoring module
[0074] This module acts as a bridge between the system and the underlying graphics services. Its implementation is adapted based on the system environment. For example, it adapts the Screen service interface in the QNX system; and it adapts graphics rendering management services based on the Wayland protocol, such as ilm (Input Layer Management), in the Linux system.
[0075] When the module starts, it performs initialization, registers the system graphics service, and creates communication interface servers (SOME / IP, PPS).
[0076] One of its core functions is to register and listen to system graphics services to obtain system layer events. For example, it can listen for events such as applications creating layers, destroying layers, or modifying layer properties.
[0077] Its second core function is to respond to the comparison results of the graphics attribute configuration management module and call the system graphics service interface to set the layer attributes of the instructions or events described therein. Whether processing external control flow or internal event flow, the final attribute setting action is completed by this module by calling the underlying system graphics service interface (such as Screen API or ilmAPI).
[0078] In addition, when this module detects system layer events (such as layer creation or attribute modification), it executes the following process to complete mandatory control (corresponding to...). Figure 7 ):
[0079] 1. Event Reporting: The module obtains the layer's identifier and current attributes from the event and immediately outputs them to the Graphic Attribute Configuration Management module for comparison.
[0080] 2. Decision Execution: The module receives and responds to the comparison results returned by the graphical attribute configuration management module.
[0081] If the result is that the layer does not exist or the attributes are different, the module will call the system graphics service interface according to the attribute setting instructions issued by the configuration management module to refresh the system layer attributes to the values specified by the instructions (this is invisible for unconfigured layers; this is the baseline value in the cache for layers with deviated attributes).
[0082] If the result is that the attributes are no different, then the module does not perform any processing.
[0083] This mechanism ensures that any layer changes that occur at the system level and are not centrally controlled can be detected and corrected in a timely manner.
[0084] That is, the execution subject: This module is called and executed by the main process and then waits for input.
[0085] Input: Receives graphics attribute control input and graphics event input from the graphics attribute control interface and the graphics service / protocol interface, respectively.
[0086] Processing: First, if graphics control information is received from the graphics attribute control interface, and the graphics attribute configuration management returns "the layer exists but the attributes are different", then the graphics attributes in the system are refreshed using the graphics service / protocol interface. If a layer event is received from the graphics service / protocol interface callback interface, then the attributes associated with the layer are obtained and output to the graphics attribute configuration management. Finally, based on the output status of the graphics attribute configuration management, it is determined whether to reset the layer attributes.
[0087] Output: If the status returned by the graphics attribute configuration management requires updating the layer attributes, the attributes will be synchronized and output to the graphics service / protocol interface again.
[0088] Example 2
[0089] III. System Workflow and Timing
[0090] The control method of this system, executed by the aforementioned system, mainly includes the following steps:
[0091] 1. Startup sequence, such as Figure 5 As shown:
[0092] Prioritize loading layer configuration files. This is because system layers and external graphics controls depend on the default layer properties, hence the priority for loading them.
[0093] Secondly, the registration of the graphics system service function is initiated. Since external graphics control ultimately depends on the system's graphics system, it is initiated earlier than the external interface.
[0094] Finally, start the graphical control interface. Once the configuration file and system graphical service have started, the functional dependencies of the external interface are satisfied, and the interface function can be started.
[0095] The application controls the event handling timing of the layer; this is an external control flow, such as... Figure 6 As shown:
[0096] Step 1: The external module calls the graphics property control interface and inputs the property parameters.
[0097] Step 2: The graphical attribute control interface parses the instructions and passes them to the graphical attribute configuration management module.
[0098] Step 3: The graphic attribute configuration management module performs attribute comparison:
[0099] a. If the layer attribute does not exist in the cache, add the input attribute parameters to the cache and return the corresponding status.
[0100] b. If the layer attribute exists and differs from the input attribute, update the difference value of the input attribute to the cache and return the attribute difference status.
[0101] c. If the layer attributes exist but there are no differences in the attributes, return the status of "no differences in attributes".
[0102] Step 4: If the comparison returns a state where the attributes differ, the graphics attribute configuration management module (which may be triggered or assisted by the interface module) sends an instruction to the graphics service / protocol registration and listening module, which then calls the system graphics service interface to set the system layer attributes so that they take effect immediately.
[0103] 2. System layer event handling sequence, this is the internal event flow, such as... Figure 7 As shown:
[0104] Step 1: The graphics system generates an event when an application creates a layer or modifies its properties. The event listener callback function of the graphics service / protocol registration and listening module is then invoked.
[0105] Step 2: This module obtains the layer attributes associated with the event and reports them to the graphics attribute configuration management module.
[0106] Step 3: The graphic attribute configuration management module performs attribute comparison:
[0107] a. If the layer attributes do not exist in the cache, add the layer identifier and its attributes to the cache, set its visibility attribute to invisible, and return the corresponding state.
[0108] b. If the layer properties exist and differ from the cached properties, the cached properties will be used as the reference, and the corresponding status will be returned.
[0109] c. If the layer attributes exist but are identical, return the corresponding status.
[0110] Step 4: When there are differences in attribute comparison or the layer does not exist, the graphics attribute configuration management module sends an instruction to the graphics service / protocol registration and listening module. The latter calls the system graphics service interface to refresh the system layer attributes based on the cached attributes, thus completing the forced correction.
[0111] IV. About Storage Media
[0112] The present invention also relates to a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the unified control method for graphics attributes as defined in Embodiment 2. This medium can be any non-transient tangible medium containing or storing a program, such as ROM, RAM, disk, optical disk, etc.
[0113] In summary, the innovative points and effects of this invention are as follows:
[0114] 1. High adaptability. Provides layer control and management entirely based on product requirements.
[0115] Technical features: Unifies the management of system and graphics applications, and provides a unique graphics settings interface, allowing for flexible and varied layer display requirements.
[0116] The difference from existing technologies: Existing layer control is based on the application itself and cannot be uniformly managed and controlled from the outside. It cannot flexibly adapt to product needs and achieve external condition-related switching.
[0117] 2. High portability. This method can be implemented and effective in existing system environments without requiring adaptation for graphics-related applications.
[0118] Technical features: By interfacing with the graphics services / protocols in the system, it enables the monitoring and management of all graphics events in the system, achieving seamless management and control of graphics applications.
[0119] Technical effect: Layer information is obtained directly from the graphics base service, without the need for graphics application adaptation to meet the function.
[0120] 3. High controllability over layers. Layer attribute management is primarily based on configuration and input control:
[0121] Technical features: The layer attribute control of this method is mainly based on the configuration file and external interface input. Existing layers in the system and layers to be created will be set to the attributes input by the configuration or control interface. Unconfigured layers will be directly hidden and excluded from the effective display range.
[0122] Technical benefits: It avoids "unexpected events" in the application of unknown layers, allows for complete and proactive control over the properties of any layer, and offers strong controllability.
[0123] 4. Non-intrusive design. Whether this method runs or not does not affect any layer application in the current system. When this method is running, unified layer control and management functions can be used; when not running, each layer application follows the system's default layer management strategy.
[0124] This invention has been implemented and tested on QNX and Linux systems. In the QNX environment, the Screen graphics service is adapted; in the Linux environment, the Wayland-based ILM service is adapted. The external control interface communicates via the SOME / IP protocol. Through a predefined JSON configuration file, unified management of multiple application layers, including boot animation (instruments & IVI), factory reset animation, navigation (projected instruments), AVM applications, and instrument HMI, has been successfully achieved. This effectively controls their display timing and attributes, and automatically hides unconfigured third-party application layers, fully achieving the invention's objectives.
[0125] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A unified control system for graphical attributes, characterized in that, include: The graphics attribute configuration management module is used to load and cache predefined graphics attribute configuration files to establish and maintain the mapping relationship between layer identifiers and graphics attributes; The graphics attribute control interface module is used to receive graphics control commands from external sources. The graphics service / protocol registration and listening module is used to register and listen to system graphics services in order to obtain system layer events; The graphical attribute configuration management module is used for: Receive graphics control commands from the graphics attribute control interface module and system layer events from the graphics service / protocol registration and listening module; Based on the mapping relationship, the layer attributes associated with the received graphics control commands or system layer events are compared; The graphics service / protocol registration and listening module is used to respond to the comparison result of the graphics attribute configuration management module by calling the system graphics service interface to set the layer attributes described by the instruction or event to the system.
2. The unified control system for graphic attributes according to claim 1, characterized in that, After comparing the received graphics control commands, the graphics attribute configuration management module will execute the following steps if the comparison results show that the layer exists but the attributes are inconsistent: Update the corresponding attribute values in the mapping relationship; Send attribute setting instructions to the graphics service / protocol registration and monitoring module.
3. The unified control system for graphic attributes according to claim 2, characterized in that, The graphics attribute control interface module is used to forward the received graphics control commands to the graphics attribute configuration management module; and to receive the comparison results returned by the graphics attribute configuration management module. If the comparison result indicates that the layer exists but the attributes are inconsistent, the module triggers or assists the graphics attribute configuration management module to send the attribute setting command to the graphics service / protocol registration and listening module, so as to call the system graphics service interface to set the layer attributes corresponding to the graphics control command to the system.
4. The unified control system for graphic attributes according to claim 1, characterized in that, After comparing the received system layer events, if the comparison result shows that the layer identifier does not exist in the mapping relationship, the graphics attribute configuration management module executes the following: Add the layer identifier and its attributes to the mapping relationship, and set the visibility attribute of the layer identifier to invisible; Send an attribute setting command to the graphics service / protocol registration and listening module to set the layer corresponding to the event to an invisible state in the system.
5. A unified control system for graphical attributes according to claim 1 or 4, characterized in that, After comparing the received system layer events, if the comparison result shows that the layer exists but the attributes are inconsistent, the graphics attribute configuration management module will execute: Based on the cached attribute values in the mapping relationship, an attribute setting instruction is sent to the graphics service / protocol registration and listening module to refresh the attribute values of the layer corresponding to the event in the system to the cached values.
6. The unified control system for graphic attributes according to claim 1, characterized in that, The graphical attribute configuration file is a JSON format file; the mapping relationship is cached using an unordered mapping container from the C++ standard library.
7. A unified control system for graphic attributes according to claim 1, characterized in that, The graphics attribute control interface module receives external commands via inter-process communication methods including at least one of the SOME / IP protocol or PPS mechanism.
8. A unified control system for graphic attributes according to claim 1, characterized in that, The system graphics service is either the Screen graphics service of the QNX operating system or the input layer management service based on the Wayland protocol under the Linux operating system.
9. A method for unified control of graphic attributes, characterized in that, The method is executed by a unified control system for graphic attributes as described in any one of claims 1 to 8, the method comprising: The mapping relationship is established and maintained through the graphical attribute configuration management module. The system receives external graphics control commands through the graphics attribute control interface module and listens for system layer events through the graphics service / protocol registration and listening module. The graphic attribute configuration management module compares the layer attributes associated with the received instructions or events. In response to the comparison result, the graphics service / protocol registration and listening module sets the layer attributes described by the instruction or event to the system.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the unified control method for graphics attributes as described in claim 9.