Intelligent cabin image display control method, device and equipment and readable storage medium

Abstract

The invention discloses an intelligent cabin image display control method, an intelligent cabin image display control device, intelligent cabin image display control equipment and a readable storage medium, and relates to the technical field of graphics processor resource optimization. Generating a target display request based on the target buffer area data, the target buffer area size and a target window name of the client, and sending the target display request to a server; when the server determines that the target buffer area data does not need to be synthesized based on the target window name and the target buffer area size, copying the target buffer area data to a target frame buffer area of a target screen corresponding to the client; and a direct rendering manager (DRM) displays the data of the target frame buffer area to a target screen. According to the method and the device, GPU consumption in an intelligent cabin image display process can be effectively reduced, so that the frame rate is improved, and the display fluency is improved.

Description

Technical Field

[0001] This application relates to the field of graphics processor resource optimization technology, specifically to a smart cockpit image display control method, apparatus, device, and readable storage medium. Background Technology

[0002] X11 is a computer graphics display protocol called the X Window System, primarily responsible for managing graphics display and user input devices. X11 employs a client-server model, mainly consisting of three parts: X-Server, X-Client (i.e., the application), and the window manager. The X-Server is the central component of the X Window System, responsible for managing input / output devices such as the screen, keyboard, and mouse. It also coordinates communication between the X-Client and the window manager, receiving information from input devices and transmitting it to the X-Client, then outputting the images from the X-Client to the screen for display. The X-Client processes actions from the X-Server, converting them into image data, and then sends this image data back to the X-Server. The window manager, a special case of the X-Client, is primarily responsible for managing the appearance and behavior of windows.

[0003] In related technologies, from the start of rendering by the X-Client to the final image display on the screen, at least five steps are involved: X-Client rendering, redirecting the client buffer to the off-screen buffer, the window manager compositing the off-screen buffer, the window manager rendering the composited data to the front buffer, and the X-Server copying the data in the front buffer to the physical screen's frame buffer. These steps consume GPU (Graphics Processing Unit) resources. It is evident that for graphics-intensive tasks and multi-screen displays like smart cockpits, the GPU computing power and video memory resources are limited, but the resource requirements are high. If traditional X11 technology (which consumes a large amount of GPU resources) is used to implement the image display of smart cockpits, it will inevitably lead to a low frame rate, resulting in performance issues such as unsmooth display. Summary of the Invention

[0004] This application provides a method, apparatus, device, and readable storage medium for controlling the image display of an intelligent cockpit, which can solve the technical problem of low frame rate caused by using traditional X11 technology to realize the image display of an intelligent cockpit in the prior art.

[0005] In a first aspect, embodiments of this application provide a smart cockpit image display control method, comprising the following steps: After the client renders the image to be displayed and obtains the target buffer data, it generates a target display request based on the target buffer data, the target buffer size, and the client's target window name, and sends it to the server. When the server determines that the target buffer data does not need to be synthesized based on the target window name and / or the target buffer size, the target buffer data is copied to the target frame buffer of the target screen corresponding to the client. The Direct Render Manager (DRM) displays the target frame buffer data onto the target screen.

[0006] In conjunction with the first aspect, in one embodiment, prior to the step of determining that the target buffer data does not require compositing processing based on the target window name and / or the target buffer size, the method further includes: The server determines whether a first mapping relationship exists in a preset target mapping table. The window name and buffer size in the first mapping relationship are the same as the target window name and target buffer size, respectively. The target mapping table is used to store the mapping relationship between the window name and buffer size that does not need to be processed by compositing. If it exists, then the target buffer data is determined not to require synthesis processing; If it does not exist, then the target buffer data is determined to need to be synthesized.

[0007] In conjunction with the first aspect, in one embodiment, after the step of determining that the target buffer data needs to be synthesized, the method further includes: The server redirects the target buffer data to the off-screen buffer corresponding to the client; The window manager performs composite processing on the data in the off-screen buffer and then renders it to the target frame buffer.

[0008] In conjunction with the first aspect, in one implementation, the window manager performs compositing processing on the data in the off-screen buffer and then renders it to the target frame buffer, including: The window manager retrieves off-screen buffer data from the off-screen buffers of different clients; The window manager synthesizes all the off-screen buffer data obtained to obtain the synthesized data; The window manager renders the composite data to the target frame buffer.

[0009] In conjunction with the first aspect, in one embodiment, prior to the step of copying the target buffer data to the target frame buffer of the target screen corresponding to the client, the method further includes: If the server receives multiple target display requests from clients at the same time, and the target buffer data in each target display request does not require merging processing, the target buffer data corresponding to the client with the highest priority will be used as the copy object, and the target buffer data corresponding to other clients will be discarded.

[0010] Secondly, embodiments of this application provide an intelligent cockpit image display control device, comprising: The client is used to render the image to be displayed to obtain the target buffer data, generate a target display request based on the target buffer data, the target buffer size and the client's target window name and send it to the server; A server is configured to copy the target buffer data to the target frame buffer of the target screen corresponding to the client when it is determined, based on the target window name and / or the target buffer size, that the target buffer data does not require compositing processing. The Direct Render Manager (DRM) is used to display the target frame buffer data onto the target screen.

[0011] In conjunction with the second aspect, in one implementation, the server is specifically used for: Determine whether a first mapping relationship exists in the preset target mapping table, wherein the window name and buffer size in the first mapping relationship are the same as the target window name and target buffer size, respectively. If it exists, then the target buffer data is determined not to require synthesis processing; If it does not exist, then the target buffer data is determined to need to be synthesized.

[0012] In conjunction with the second aspect, in one embodiment, the intelligent cockpit image display control device further includes a window manager; The server is also configured to redirect the target buffer data to an off-screen buffer corresponding to the client. The window manager is used to synthesize the data in the off-screen buffer and then render it to the target frame buffer.

[0013] In conjunction with the second aspect, in one implementation, the window manager is specifically used for: Retrieve off-screen buffer data from off-screen buffers of different clients respectively; All the off-screen buffer data acquired are combined to obtain composite data; The synthesized data is rendered to the target frame buffer.

[0014] In conjunction with the second aspect, in one implementation, the server is further configured to: If multiple target display requests are received from clients at the same time, and the target buffer data in each target display request does not require compositing, the target buffer data corresponding to the client with the highest priority is used as the copy object, and the target buffer data corresponding to other clients is discarded.

[0015] Thirdly, embodiments of this application provide an intelligent cockpit image display control device, which includes a processor, a memory, and an intelligent cockpit image display control program stored in the memory and executable by the processor. When the intelligent cockpit image display control program is executed by the processor, it implements the steps of the aforementioned intelligent cockpit image display control method.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing an intelligent cockpit image display control program, wherein when the intelligent cockpit image display control program is executed by a processor, it implements the steps of the aforementioned intelligent cockpit image display control method.

[0017] The beneficial effects of the technical solutions provided in this application include: After the client renders the image to be displayed to obtain the target buffer data, a target display request is generated based on the target buffer data, the target buffer size, and the client's target window name. The server then determines whether the target buffer data needs compositing processing based on the target window name and target buffer size, thus determining whether compositing processing through the window manager is required. For target buffer data that does not require compositing processing, it is directly copied by the server to the target frame buffer of the target screen corresponding to the client, and then submitted by the DRM to the target screen for full-screen window display. This avoids the GPU consumption caused by processing through the window manager, effectively reducing GPU resource consumption during the intelligent cockpit image display process, thereby improving the frame rate and enhancing the smoothness of the display. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an embodiment of the intelligent cockpit image display control method of this application; Figure 2 This is a schematic diagram of the native display process of the traditional X11; Figure 3 This is a schematic diagram of the display process involved in the embodiments of this application; Figure 4 This is a schematic diagram of the functional modules of an embodiment of the intelligent cockpit image display control device of this application; Figure 5 This is a schematic diagram of the hardware structure of the intelligent cockpit image display and control device involved in the embodiments of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0021] In a first aspect, embodiments of this application provide a smart cockpit image display control method.

[0022] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the intelligent cockpit image display control method of this application. Figure 1 As shown, the intelligent cockpit image display control method includes: Step S10: After the client renders the image to be displayed and obtains the target buffer data, it generates a target display request based on the target buffer data, the target buffer size, and the client's target window name, and sends it to the server.

[0023] As an example, it should be understood that the client and server in this embodiment can be X-Client and X-Server under the X11 protocol, or client and server under the TinyX protocol (i.e., lightweight X11 protocol), or client and server under protocols with similar properties or architectures to the X11 protocol, etc., and are not limited here. However, for the sake of brevity, subsequent embodiments will use X-Client and X-Server under the X11 protocol as examples to explain the intelligent cockpit image display control method, principles, etc.

[0024] Understandably, X11 is based on a desktop system's graphics display protocol, allowing windows to be easily dragged between multiple screens. Therefore, in X1's native design, image data from multiple physical screens enters a front buffer encompassing all screen sizes. When a window on screen 1 needs to be moved to screen 2, simply copying the data from the front buffer representing the display area on screen 1 to screen 2 easily enables window dragging. Therefore, see... Figure 2As shown, if the image display of a smart cockpit is implemented using traditional X11 technology, it typically requires X-Client, X-Server, and the window manager to execute the following native X11 process to complete data interaction before the data rendered by X-Client can be finally displayed on the screen: (1) After the X-Client finishes rendering, it submits the output to the X-Server; the X-Client rendering requires GPU resources, and the consumption of these GPU resources is essential.

[0025] (2) The X-Server redirects the buffer rendered by the X-Client to an off-screen buffer for window management; the redirection involves a data transfer, which consumes GPU resources.

[0026] (3) The window manager obtains off-screen buffer data from multiple X-Clients.

[0027] (4) The window manager synthesizes the multiple off-screen buffer data obtained; the synthesis process requires GPU resources.

[0028] (5) The window manager renders the composited data to the front buffer allocated by the X-Server for display. The front buffer includes the size of all physical screens. This process involves a data transfer, which consumes GPU resources.

[0029] (6) The X-Server copies data from the front buffer to the frame buffer of each physical screen (e.g., screen 1 to screen 3) to submit it to the screen for display via DRM (Direct Rendering Manager); this process does not consume GPU resources.

[0030] Based on the above X11 native workflow, it can be seen that five steps, from X-Client rendering to the final display of the image on the screen, require GPU resources. However, for graphics-intensive tasks and multi-screen embedded platforms like smart cockpits, GPU computing power and video memory resources are limited, yet resource requirements are high. If the X11 native workflow is used to implement the image display of smart cockpits, it will inevitably lead to a low frame rate, resulting in performance issues such as choppy display.

[0031] It should be understood that smart cockpit products typically possess the following characteristics: See Figure 3As shown, the smart cockpit has three screens. Screen 1 is the head-up display (HUD), with only one full-screen window; data sent to this screen for display does not need to be composited. Screen 2 is the central control screen, with multiple full-screen applications (such as 360-degree panoramic imaging, maps, and entertainment). These applications are displayed in a time-sharing manner, meaning data sent to this screen also does not need to be composited, although there is a display priority among the applications. Screen 3 is the instrument cluster screen, which contains applications or windows including functional safety icons, driving data, and a mini-map. These different applications or windows need to be composited before being displayed simultaneously on the instrument cluster screen; that is, data sent to the instrument cluster screen for display requires composite processing. In summary, window data displayed through screens 1 and 2 does not require composite processing, while window data displayed through screen 3 does require composite processing.

[0032] Furthermore, it should be noted that there is a display mapping relationship between the X-Client (i.e., the application, such as 360-degree panoramic imaging AVM, etc.) and the screen, and this display mapping relationship is pre-configured. For example, there are X-Client1, 2, and 3, and the window count data of X-Client1 needs to be sent to screen 1, the window count data of X-Client2 needs to be sent to screen 2, and the window count data of X-Client3 needs to be sent to screen 3. In this case, the display mapping relationships between X-Client1 and screen 1, X-Client2 and screen 2, and X-Client3 and screen 3 can be constructed respectively. It can be seen that the window count data of X-Client1 and X-Client2 do not need to be composited, while the window count data of X-Client3 needs to be composited before it can be transmitted to screen 3 for display. Based on this, it is only necessary to know the window name of the X-Client and the width and height dimensions of the buffer it renders to determine which screen the window count data of the X-Client needs to be sent to. In other words, it is also known whether the window count data of the X-Client needs to be composited.

[0033] To effectively reduce GPU consumption during image display, this embodiment optimizes the X11 display process based on the above characteristics of the smart cockpit product. Specifically, it determines which X-Client window data needs to be composited and which does not by using the display mapping relationship between X-Client and the screen. This determines whether the window manager needs to participate in the composite process, thereby changing the flow of window data and avoiding GPU consumption caused by window manager processing, thus achieving the goal of reducing GPU consumption.

[0034] Therefore, after X-Client obtains the target buffer data by rendering the image to be displayed, see... Figure 3As shown, a target display request will be generated and sent to the X-Server based on the target buffer data, the target buffer size (i.e., the width and height of the buffer), and the target window name of the X-Client. It should be noted that the methods and principles by which the X-Client implements image rendering are common knowledge in the field, and therefore will not be elaborated upon here for the sake of brevity.

[0035] Step S20: When the server determines that the target buffer data does not need to be synthesized based on the target window name and / or the target buffer size, the target buffer data is copied to the target frame buffer of the target screen corresponding to the client.

[0036] In this exemplary embodiment, all X-Clients submit display requests to the X-Server, allowing the X-Server to distinguish which X-Client window data needs to be managed by the window manager and which does not, based on the X-Client's window name and / or the size of the rendered buffer. This changes the path of X-Client window data to the screen, reducing the number of GPU rendering operations and thus reducing GPU resource usage. It is understood that the determination of whether window data needs to be managed by the window manager can be based on the window name, the buffer size, or a combination of both. Of course, it can also be based on other parameters besides the window name and buffer size, which is not limited here. Specifically, in the following embodiments, taking the determination of whether window data needs to be managed by the window manager by combining the window name and the buffer size as an example, when the X-Server receives the target display request sent by the X-Client, it will determine whether the target buffer data needs to be composited based on the target window name and the target buffer size in the target display request. If no composite processing is required, it is determined that the window data does not need to enter the window manager. Therefore, the target buffer data can be directly copied to the target frame buffer of the target screen corresponding to the X-Client. For example, the target buffer of X-Client1 can be directly copied to the frame buffer1 corresponding to screen 1.

[0037] For example, assuming that the target window name and target buffer size in the target display request of X-Client2 satisfy the condition strstr(window_name, “AVM”)&&width == 2560&&height == 1440, then X-Server will know that this is a 360 panoramic image request that does not need to be synthesized. At this time, it will not enter the window manager but will directly copy the buffer data to the frame buffer of the central control screen (i.e., screen 2).

[0038] Step S30: The Direct Render Manager (DRM) displays the data of the target frame buffer onto the target screen.

[0039] Exemplary and understandable, DRM is part of the Linux kernel used to manage graphics hardware and provide support for direct rendering. The DRM ioctl interface is a way to interact with the DRM driver, allowing user-space programs to send commands to the kernel to control the graphics hardware. Therefore, user-space programs (such as X11) submit display requests to the kernel-space DRM driver through the DRM ioctl interface provided by libdrm (a library based on the kernel DRM). When the kernel DRM driver receives the X11's DRM ioctl request, it updates the framebuffer to the corresponding screen for display. Thus, in this embodiment, when the DRM receives the DRM ioctl request, it updates the data in the target framebuffer to the target screen for display.

[0040] It should be understood that in this embodiment, for screens 1 and 2, the X-Client window is displayed in full screen and does not require the window manager to participate in compositing. Therefore, when implementing image display, only the following two steps need to be completed: 1) After the X-Client finishes rendering, it submits the data to the X-Server for display. The X-Client rendering consumes GPU resources and is essential; 2) The X-Server copies the X-Client's buffer to the frame buffer of the corresponding physical screen. At this time, it no longer participates in the management and compositing of the off-screen buffer of the window manager, but directly submits it to the screen for display through DRM. Of course, this also consumes GPU resources. It can be seen that this embodiment only requires two GPU consumption steps. In summary, this embodiment reduces GPU resource consumption by shortening the data submission path of the windows corresponding to screens 1 and 2, thereby improving the frame rate during the intelligent cockpit image display process and thus improving the smoothness of the display. For the native X11 workflow, although screen 1 and screen 2 do not need to be composited, the window data of screen 1 and screen 2 will be managed by the window manager because it is configured with a window manager, which consumes a lot of GPU resources. This embodiment reduces the GPU consumption from 5 times in the native X11 workflow to 2 times.

[0041] Furthermore, in one embodiment, before the step of copying the target buffer data to the target frame buffer of the target screen corresponding to the client, the method further includes: If the server receives multiple target display requests from clients at the same time, and the target buffer data in each target display request does not require merging processing, the target buffer data corresponding to the client with the highest priority will be used as the copy object, and the target buffer data corresponding to other clients will be discarded.

[0042] As an example, in this embodiment, for screen 1, only one X-Client submits data for display, so the X-Server can directly copy its target buffer data to the frame buffer. For screen 2, several X-Clients may be submitting data for display to the X-Server at the same time. In traditional X11 technology, all submitted application data is cached in the screen's frame buffer, which not only consumes resources but also leads to high resource utilization. However, in this embodiment, the X-Server arbitrates the priority of these X-Clients to copy the buffer data of high-priority X-Clients to the frame buffer of the corresponding physical screen, while discarding the buffer data of low-priority X-Clients, thereby reducing resource utilization and avoiding resource consumption.

[0043] Further, in one embodiment, before the step of determining that the target buffer data does not require compositing processing based on the target window name and / or the target buffer size, the method further includes: The server determines whether a first mapping relationship exists in a preset target mapping table. The window name and buffer size in the first mapping relationship are the same as the target window name and target buffer size, respectively. The target mapping table is used to store the mapping relationship between the window name and buffer size that does not need to be processed by compositing. If it exists, then the target buffer data is determined not to require synthesis processing; If it does not exist, then the target buffer data is determined to need to be synthesized.

[0044] As an example, in this embodiment, all X-Clients that do not require compositing are determined based on the display mapping relationship between X-Client and the screen. A mapping relationship is constructed between the window name of each X-Client and the buffer size it renders. For example, if the window name of X-Client1 is window1 and its buffer size is width == xxxx && height == yyyy, then a mapping relationship is established between window1 and width == xxxx && height == yyyy to form a target mapping table. It can be seen that the mapping relationship stored in the target mapping table is the correspondence between the window name and buffer size of X-Clients that do not require compositing.

[0045] Therefore, when the X-Server receives a target display request from the X-Client, it can traverse the mapping relationships in the target mapping table to determine if there exists a mapping relationship in the target mapping table that is exactly the same as the target window name and the target buffer size. If it exists, it is determined that the target buffer data does not need to be composited; otherwise, it is determined that the target buffer data needs to be composited. For example, suppose the target mapping table includes a mapping relationship between AVM and width == 2560 && height == 1440. If the target window name is AVM and the target buffer size is width == 2560 && height == 1440, then traversing the target mapping table will find the first mapping relationship that is exactly the same as the target window name and the target buffer size, and it will be determined that the target buffer data does not need to be composited.

[0046] It should be noted that, in addition to determining whether buffer data needs compositing by constructing a target mapping table, the information regarding whether compositing is required can also be configured directly based on the display mapping relationship between the X-Client and the screen, specifying the window name and buffer size for each X-Client. For example, for X-Client1 corresponding to screen 1, a mapping relationship is constructed between window1 and width == xxxx && height == yyyy, and a compositing field is configured for this mapping relationship to indicate whether the data of X-Client1 needs to be composited. For example, a compositing field set to 1 indicates that compositing is required, while a compositing field set to 0 indicates that compositing is not required. Therefore, when the X-Server receives a target display request sent by the X-Client, it will traverse all mapping relationships to find the mapping relationship corresponding to the target window name and target buffer size, and determine whether the target buffer data needs to be composited based on whether the compositing field in the found mapping relationship is set to 1 or 0.

[0047] Furthermore, in one embodiment, after the step of determining that the target buffer data needs to be synthesized, the method further includes: The server redirects the target buffer data to the off-screen buffer corresponding to the client; The window manager performs composite processing on the data in the off-screen buffer and then renders it to the target frame buffer.

[0048] As an example, in this embodiment, when the X-Server determines that the target buffer data needs to be composited based on the target window name and target buffer size, it indicates that the data from multiple X-Clients or multiple windows of a single X-Client need to be composited before being displayed on the same screen. In other words, the window manager needs to participate in the compositing process. Therefore, see [link to relevant documentation]. Figure 3 As shown, X-Server first redirects the target buffer data to the off-screen buffer corresponding to X-Client. Then, the window manager performs composite processing on the data in the off-screen buffer and renders it directly to the target frame buffer of the target screen corresponding to X-Client. Instead of rendering the composite data to the front buffer allocated by X-Server for display and having X-Server copy the data from the front buffer to the frame buffer of each physical screen, this reduces GPU resource consumption by one step.

[0049] For example, assuming the target window name and target buffer size in the target display request of X-Client3 satisfy the condition strstr(window_name,“HMI”)&&width == 1920&&height == 720, then X-Server will know that this is an instrument application request that needs to be composited. It will then enter the window manager to composite the data and copy it to the frame buffer of the instrument screen (i.e., screen 3). It can be seen that the target buffer data of X-Client3 no longer enters the front buffer after being composited, but goes directly to the frame buffer of screen 3, thereby reducing one GPU resource consumption.

[0050] Furthermore, in one embodiment, the window manager performs compositing processing on the data in the off-screen buffer and then renders it to the target frame buffer, including: The window manager retrieves off-screen buffer data from the off-screen buffers of different clients; The window manager synthesizes all the off-screen buffer data obtained to obtain the synthesized data; The window manager renders the composite data to the target frame buffer.

[0051] As an example, in this embodiment, for scenarios where data from multiple X-Clients or multiple windows of a single X-Client needs to be composited and displayed on the same screen 3, the window manager needs to participate in the compositing. Therefore, when implementing image display, only the following five steps need to be completed: 1) After the X-Client finishes rendering, it submits the data to the X-Server for display. X-Client rendering is essential and consumes GPU resources. 3) The X-Server redirects the X-Client's buffer to an off-screen buffer for window management. This redirection involves a data transfer and consumes GPU resources. 4) The window manager retrieves off-screen buffer data from multiple X-Clients. 5) The window manager composites the off-screen buffer data, which consumes GPU resources. 6) The window manager renders the composited data directly to the corresponding physical screen's frame buffer, bypassing the front buffer to reduce copying from the front buffer to the physical screen's frame buffer. Finally, it submits the data to the screen for display via DRM, consuming GPU resources. Therefore, this embodiment reduces GPU resource consumption by shortening the data delivery path for the window corresponding to screen 3, requiring only 4 GPU operations. This reduces the GPU consumption from 5 in the native X11 workflow to 4.

[0052] In summary, to address the aforementioned issue of multi-service, multi-screen display on embedded platforms, this embodiment optimizes the GPU resource consumption of the X-Server and window manager to ensure smooth display. Since the display between the three physical screens in the smart cockpit does not require dragging, this embodiment removes the front buffer natively present in the X11, saving VRAM (Video Random Access Memory) and reducing GPU consumption when data from each X-Client is stitched to the front buffer. However, since screen 3 requires compositing, a window manager must be configured. But once a window manager is present, all window data in the native design must enter the window manager's off-screen buffer and ultimately the front buffer. Therefore, this embodiment also adjusts the data flow of the X-Clients corresponding to screens 1 and 2 that do not require compositing to reduce GPU resource consumption. In summary, by shortening the path from X-Client data to screen display, GPU resource consumption is reduced. Furthermore, for the display of the three screens, after optimizing the processes of X-Server and Window Manager, the GPU resources consumed by X-Server and Window Manager are reduced, from a high GPU utilization of 37% before optimization to 12% after optimization.

[0053] Secondly, embodiments of this application also provide an intelligent cockpit image display control device.

[0054] In one embodiment, reference is made to Figure 4 , Figure 4 This is a schematic diagram of the functional modules of an embodiment of the intelligent cockpit image display control device of this application. Figure 4 As shown, the intelligent cockpit image display control device includes: The client is used to render the image to be displayed to obtain the target buffer data, generate a target display request based on the target buffer data, the target buffer size and the client's target window name and send it to the server; A server is configured to copy the target buffer data to the target frame buffer of the target screen corresponding to the client when it is determined, based on the target window name and / or the target buffer size, that the target buffer data does not require compositing processing. The Direct Render Manager (DRM) is used to display the target frame buffer data onto the target screen.

[0055] Furthermore, in one embodiment, the server is specifically used for: Determine whether a first mapping relationship exists in the preset target mapping table, wherein the window name and buffer size in the first mapping relationship are the same as the target window name and target buffer size, respectively. If it exists, then the target buffer data is determined not to require synthesis processing; If it does not exist, then the target buffer data is determined to need to be synthesized.

[0056] Furthermore, in one embodiment, the intelligent cockpit image display control device further includes a window manager; The server is also configured to redirect the target buffer data to an off-screen buffer corresponding to the client. The window manager is used to synthesize the data in the off-screen buffer and then render it to the target frame buffer.

[0057] Furthermore, in one embodiment, the window manager is specifically used for: Retrieve off-screen buffer data from off-screen buffers of different clients respectively; All the off-screen buffer data acquired are combined to obtain composite data; The synthesized data is rendered to the target frame buffer.

[0058] Furthermore, in one embodiment, the server is also used for: If multiple target display requests are received from clients at the same time, and the target buffer data in each target display request does not require compositing, the target buffer data corresponding to the client with the highest priority is used as the copy object, and the target buffer data corresponding to other clients is discarded.

[0059] The functions of each part of the above-mentioned intelligent cockpit image display control device correspond to the steps in the above-mentioned intelligent cockpit image display control method embodiment, and their functions and implementation processes will not be described in detail here.

[0060] Thirdly, embodiments of this application provide an intelligent cockpit image display control device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0061] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of the intelligent cockpit image display control device involved in the embodiments of this application. In the embodiments of this application, the intelligent cockpit image display control device may include a processor, a memory, a communication interface, and a communication bus.

[0062] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0063] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting components within the intelligent cockpit image display and control equipment, as well as interfaces used for interconnecting the intelligent cockpit image display and control equipment with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0064] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0065] The processor can be a general-purpose processor, which can call the intelligent cockpit image display control program stored in the memory and execute the intelligent cockpit image display control method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the intelligent cockpit image display control program is called can be referred to the various embodiments of the intelligent cockpit image display control method of this application, and will not be repeated here.

[0066] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0067] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0068] The present application has a storage medium storing an intelligent cockpit image display control program, wherein when the intelligent cockpit image display control program is executed by a processor, it implements the steps of the intelligent cockpit image display control method described above.

[0069] The method implemented when the intelligent cockpit image display control program is executed can be referred to in various embodiments of the intelligent cockpit image display control method of this application, and will not be repeated here.

[0070] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0071] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0072] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0073] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0074] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0075] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0076] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for controlling the display of images in an intelligent cockpit, characterized in that, Includes the following steps: After the client renders the image to be displayed and obtains the target buffer data, it generates a target display request based on the target buffer data, the target buffer size, and the client's target window name, and sends it to the server. When the server determines that the target buffer data does not need to be synthesized based on the target window name and / or the target buffer size, the target buffer data is copied to the target frame buffer of the target screen corresponding to the client. The Direct Render Manager (DRM) displays the target frame buffer data onto the target screen.

2. The intelligent cockpit image display control method as described in claim 1, characterized in that, Before the step of determining that the target buffer data does not require compositing processing based on the target window name and / or the target buffer size, the method further includes: The server determines whether a first mapping relationship exists in a preset target mapping table. The window name and buffer size in the first mapping relationship are the same as the target window name and target buffer size, respectively. The target mapping table is used to store the mapping relationship between the window name and buffer size that does not need to be processed by compositing. If it exists, then the target buffer data is determined not to require synthesis processing; If it does not exist, then the target buffer data is determined to need to be synthesized.

3. The intelligent cockpit image display control method as described in claim 2, characterized in that, After the step of determining that the target buffer data needs to be synthesized, the method further includes: The server redirects the target buffer data to the off-screen buffer corresponding to the client; The window manager performs composite processing on the data in the off-screen buffer and then renders it to the target frame buffer.

4. The intelligent cockpit image display control method as described in claim 3, characterized in that, The window manager performs composite processing on the data in the off-screen buffer and then renders it to the target frame buffer, including: The window manager retrieves off-screen buffer data from the off-screen buffers of different clients; The window manager synthesizes all the off-screen buffer data obtained to obtain the synthesized data; The window manager renders the composite data to the target frame buffer.

5. The intelligent cockpit image display control method as described in claim 1, characterized in that, Before the step of copying the target buffer data to the target frame buffer of the target screen corresponding to the client, the method further includes: If the server receives multiple target display requests from clients at the same time, and the target buffer data in each target display request does not require merging processing, the target buffer data corresponding to the client with the highest priority will be used as the copy object, and the target buffer data corresponding to other clients will be discarded.

6. A smart cockpit image display control device, characterized in that, include: The client is used to render the image to be displayed to obtain the target buffer data, generate a target display request based on the target buffer data, the target buffer size and the client's target window name and send it to the server; A server is configured to copy the target buffer data to the target frame buffer of the target screen corresponding to the client when it is determined, based on the target window name and / or the target buffer size, that the target buffer data does not require compositing processing. The Direct Render Manager (DRM) is used to display the target frame buffer data onto the target screen.

7. The intelligent cockpit image display control device as described in claim 6, characterized in that, The server is specifically used for: Determine whether a first mapping relationship exists in the preset target mapping table, wherein the window name and buffer size in the first mapping relationship are the same as the target window name and target buffer size, respectively. If it exists, then the target buffer data is determined not to require synthesis processing; If it does not exist, then the target buffer data is determined to need to be synthesized.

8. The intelligent cockpit image display control device as described in claim 7, characterized in that: The intelligent cockpit image display control device also includes a window manager; The server is also configured to redirect the target buffer data to an off-screen buffer corresponding to the client. The window manager is used to synthesize the data in the off-screen buffer and then render it to the target frame buffer.

9. A smart cockpit image display and control device, characterized in that, The intelligent cockpit image display control device includes a processor, a memory, and an intelligent cockpit image display control program stored in the memory and executable by the processor, wherein when the intelligent cockpit image display control program is executed by the processor, it implements the steps of the intelligent cockpit image display control method as described in any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an intelligent cockpit image display control program, wherein when the intelligent cockpit image display control program is executed by a processor, it implements the steps of the intelligent cockpit image display control method as described in any one of claims 1 to 5.

Images