Vehicle-mounted instrument road condition information bar drawing method and device, electronic equipment and vehicle

Abstract

The embodiment of the invention provides a vehicle-mounted instrument road condition information bar drawing method and device, electronic equipment and a vehicle, and relates to the technical field of vehicle-mounted display, and the method comprises the steps: obtaining current road congestion state data and current road congestion distance data; the current road congestion distance data are converted into OPENGL vertex coordinate data, and the current road congestion state data are converted into OPENGL vertex coloring data; using the OPENGL vertex coordinate data and the OPENGL vertex coloring data to draw a road condition information strip thick line; according to the drawn road condition information strip thick line, current road condition information strip texture data is generated; and rendering the texture data of the current road condition information bar, and displaying the current road condition information bar. According to the method, the road condition information bar is drawn by using the line segment drawing function of the OPENGL, so that the computing power consumed by drawing and rendering the road condition information bar of the vehicle-mounted instrument is reduced, and a relatively low resource consumption state is gained for a CPU and a GPU.

Description

Technical Field

[0001] The present application relates to the field of vehicle-mounted display technology, and in particular to a method, device, electronic equipment and vehicle for drawing a road condition information bar of a vehicle-mounted instrument. Background Art

[0002] In existing instrument software products, it is often necessary to interact with the central control map application to draw a road condition information bar for this trip on the instrument software. The road condition information bar needs to present the congestion severity information of this driving route and the proportion of different degrees of congestion distance in this driving in real time.

[0003] There are generally two rendering display schemes in the existing instrument software developed based on the KanziStudio3D rendering engine. The first scheme is that the central control map program first draws the road condition bar, and then encodes this image into a binary data stream. This data stream is then transmitted to the instrument rendering engine, which then creates it as a texture image according to the corresponding image data format rules and submits it to a system such as KanziStudio for display. This method relies on the drawing of the map software and involves the transmission and processing of a large number of binary image data streams. The CPU needs to process these data streams twice: once when receiving them and once when converting them into image formats. In addition, these data are transmitted across processes, which further increases the complexity of processing and consumes a lot of CPU and GPU computing power. The second scheme is that the instrument receives the road congestion status and congestion distance information sent by the central control map software, and then creates a kanzi::node2D empty node inside KanziStudio. According to the congestion status of the road, call the kanzi::setbrushcolor() function to fill different colors; according to the congestion distance of the road, use the kanzi::setlayoutwidth() function to set the width of the kanzi::node2D node. Finally, multiple kanzi::node2D nodes with set colors and widths are added to a large kanzi::node2D node through the kanzi::node::addchild() function to present the road condition information bar. However, when the road conditions of the driving route are complex and there are multiple sections with different congestion levels (such as severe congestion, congestion, slow traffic, and smooth traffic), multiple node2D nodes can only be created to store the road conditions and fill in the corresponding colors. In this case, a lot of CPU computing power will be consumed to manage these node2D nodes. At the same time, considering that the instrument screen needs to render 30 frames per second, this means that each node2D node will be managed 30 times per second, further increasing the CPU resource consumption. Summary of the invention

[0004] The main purpose of the embodiments of the present application is to propose a method, device, electronic device and vehicle for drawing a road condition information bar of an on-board instrument, aiming to achieve drawing and rendering of the road condition information bar of the on-board instrument through OPENGL while occupying less CPU and GPU resources.

[0005] In a first aspect, the present application provides a method for drawing a road condition information bar of a vehicle-mounted instrument, the method comprising:

[0006] Obtain current road congestion status data and current road congestion distance data;

[0007] Convert the current road congestion distance data into OPENGL vertex coordinate data, and convert the current road congestion status data into OPENGL vertex shading data;

[0008] Using the OPENGL vertex coordinate data and the OPENGL vertex shading data, drawing a thick line of a road condition information bar;

[0009] Generate current road condition information bar texture data according to the drawn road condition information bar thick line;

[0010] The texture data of the current traffic condition information bar is rendered to display the current traffic condition information bar.

[0011] In a possible implementation, the step of drawing a thick line of the road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data specifically includes:

[0012] Draw a road condition information line segment using the OPENGL vertex coordinate data and the OPENGL vertex shading data;

[0013] The line segment of the road condition information bar is stretched to obtain a thick line of the road condition information bar.

[0014] In a possible implementation, the step of drawing a thick line of the road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data specifically includes:

[0015] If the OPENGL vertex coordinate data exceeds the preset OPENGL vertex coordinate range, a vertex coordinate out-of-limit warning is output;

[0016] If the OPENGL vertex coordinate data does not exceed the preset OPENGL vertex coordinate range, the OPENGL vertex coordinate data and the OPENGL vertex shading data are used to draw a thick line of the road condition information bar.

[0017] In a possible implementation, the step of drawing a thick line of the road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data specifically includes:

[0018] If the OPENGL vertex coordinate data does not change according to the preset trend, a vertex coordinate out-of-bounds warning is output;

[0019] If the OPENGL vertex coordinate data changes according to a preset trend, a thick line of a road condition information bar is drawn using the OPENGL vertex coordinate data and the OPENGL vertex shading data.

[0020] In a possible implementation, the step of obtaining current road congestion status data and current road congestion distance data specifically includes:

[0021] Obtain current road congestion status data and current road congestion distance data;

[0022] Obtain the historical road congestion status data and historical road congestion distance data corresponding to the previous frame rendering;

[0023] If the current road congestion state data is consistent with the historical road congestion state data, and the current road congestion distance data is consistent with the historical road congestion distance data, the current road congestion state data and the current road congestion distance data are discarded.

[0024] In a possible implementation, the step of rendering the texture data of the current traffic condition information bar to display the current traffic condition information bar specifically includes:

[0025] Get the texture data of the historical traffic information bar corresponding to the previous frame rendering;

[0026] If the texture data of the historical traffic information bar is consistent with the texture data of the current traffic information bar, obtaining the historical traffic information bar corresponding to the previous frame rendering, and displaying the historical traffic information bar;

[0027] If the texture data of the historical road condition information bar is inconsistent with the texture data of the current road condition information bar, the texture data of the current road condition information bar is rendered to display the current road condition information bar.

[0028] In a second aspect, the present application provides a device for drawing a road condition information bar of a vehicle-mounted instrument, the device comprising:

[0029] A road condition acquisition module is used to obtain current road congestion status data and current road congestion distance data;

[0030] A vertex conversion module, used to convert the current road congestion distance data into OPENGL vertex coordinate data, and convert the current road congestion status data into OPENGL vertex shading data;

[0031] A road condition drawing module, used for drawing a thick line of a road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data;

[0032] A texture generation module, used for generating texture data of the current road condition information strip according to the drawn thick line of the road condition information strip;

[0033] The traffic condition display module is used to render the texture data of the current traffic condition information bar and display the current traffic condition information bar.

[0034] In a third aspect, the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the method for drawing a vehicle instrument road condition information bar as described in the first aspect or any possible implementation method of the first aspect.

[0035] In a fourth aspect, the present application provides a vehicle, comprising the on-board instrument road condition information bar drawing device described in the second aspect or the electronic device described in the third aspect.

[0036] In a fifth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the method for drawing a road condition information bar of an on-vehicle instrument as described in the first aspect or any possible implementation method of the first aspect.

[0037] The method, device, electronic device and vehicle for drawing a road condition information bar for an on-board instrument proposed in the present application obtain road condition information, use OPENGL to draw a thick line of the road condition information bar, generate road condition information bar texture data according to the thick line of the road condition information bar, and render the road condition information bar texture data to display the road condition information bar. Drawing of the road condition information bar is achieved through the line segment drawing function of OPENGL, thereby greatly reducing the resource consumption occupied by drawing the road condition information bar. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 A schematic diagram of a flow chart of a method for drawing a road condition information bar of a vehicle-mounted instrument provided in an embodiment of the present application;

[0039] Figure 2 A schematic diagram of the structure of a vehicle-mounted instrument road condition information bar drawing device provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0042] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification, claims and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0044] First, some nouns involved in this application are analyzed:

[0045] OPENGL: OpenGL (Open Graphics Library) is an open standard that is widely used in game development, virtual reality, scientific visualization, computer-aided design (CAD) and other fields. OpenGL is a cross-language, cross-platform application programming interface (API) for rendering 2D and 3D vector graphics. This interface consists of nearly 350 different function calls to draw simple graphic bits to complex three-dimensional scenes. OpenGL can run on operating systems such as Windows, some UNIX platforms, and Mac OS. OpenGL is compatible with multiple programming languages, such as C++, Java, Python, etc. The efficient implementation of OpenGL utilizes graphics acceleration hardware, which is generally provided by display device manufacturers.

[0046] Texture data: Texture data is usually a 2D picture (it can also be 1D or 3D), which contains color and other information that can be mapped to the surface of a 3D model. When the model is rendered, the content of the texture image will be displayed on the surface of the model, as if it were "painted" on the surface of the model. In addition to image data, textures can also store other types of data, such as height maps, normal maps, ambient occlusion maps, etc., which play a key role in shader calculations. The format of texture data can be various, such as RGBA, RGB, grayscale, etc. These formats determine the color components and quantity of each pixel in the texture. In OpenGL, texture data can be compressed, such as png, jpg and other formats, or uncompressed, such as TGA and other formats. The system will decode the compressed image and restore it to a bitmap for texture use.

[0047] Rendering: Rendering refers to the process of using computer programs to process the model, lighting, materials, textures and other elements in a three-dimensional scene to finally generate a realistic two-dimensional image. It is one of the core tasks in computer graphics and is widely used in game development, virtual reality, film production, computer-aided design and other fields. The rendering process usually includes the following key steps: creating object models in a three-dimensional scene, including geometric shapes, materials, textures, etc. These models are the basis of rendering; transforming the models according to the user's perspective, including translation, rotation, scaling, etc.; projecting the three-dimensional model onto a two-dimensional plane to obtain a two-dimensional image; calculating the lighting effect on the surface of the object according to factors such as the position of the light source and the properties of the material; mixing the image after the lighting calculation with the background image to obtain the final rendering effect.

[0048] In existing instrument software products, it is often necessary to interact with the central control map and draw a road condition information bar for the current trip on the instrument software. The road condition information bar needs to present in real time the congestion severity information of the current driving route and the proportion of different degrees of congestion distance in this driving. There are generally two rendering display schemes in the existing instrument software developed based on the KanziStudio3D rendering engine. The first scheme is: the central control map program directly draws the road condition bar, and then encodes the road condition bar image into a binary data stream through data encoding, and transmits it to the instrument rendering engine. The rendering engine then creates a texture image according to the corresponding image data format rules after the binary data stream, and submits it to KanziStudio for display; the second scheme is: the instrument receives the road congestion status and road congestion distance information sent by the central control map software, creates a kanzi::node2D empty node inside KanziStudio, calls kanzi::setbrushcolor() in the kanzi::node2D empty node according to the road congestion status to fill different colors, and sets the width of the kanzi::node2D node according to the road congestion distance kanzi::setlayoutwidth(), and finally calls kanzi::node::addchild() on the corresponding multiple kanzi::node2D nodes that have been set with color and width, and puts them in a large kanzi::node2D node to present as a road condition information bar.

[0049] It can be seen that the road condition information bar of the first solution is completely dependent on the drawing of the map software. After the map is drawn once, the image data needs to be encoded into a binary stream for transmission. After the instrument receives it, it needs to process the image data stream again and assemble the data stream into an image format. Throughout the entire process, the CPU operation processes a large amount of binary image data stream twice, and the data is still transmitted across processes. The GPU draws the road condition bar image twice, and at the same time, it is necessary to ensure that the binary image data stream is correct and error-free. If a binary bit is lost, the image creation fails to generate a black block or cause the instrument program to crash. At the same time, the internal screen of the instrument KanziStudio is drawn 30 times per second, which means that the above process needs to be processed 30 times per second. This solution consumes a lot of CPU and GPU computing power. The second solution is to process it in the KanziStudio3D rendering engine, and draw and fill kanzi::node2D nodes according to different congestion conditions. However, if the road conditions of this driving route are complex, with multiple sections of severe congestion, congestion, slow traffic, and smooth traffic conditions, since the shader drawing inside kanzi is limited to accepting only 8 custom data inputs, it can only be drawn by continuously creating multiple node2D nodes to store the road conditions and fill in the corresponding warning colors. In this solution, the CPU computing power will be consumed to manage the node2D nodes. At the same time, kanzi needs to render and present. Under the instrument screen rendering of 30 frames per second, multiple node2D nodes will be managed 30 times, and the CPU resource consumption is too large.

[0050] In response to the problem that the existing road condition information bar drawing and rendering solutions occupy a lot of resources, this application implements a solution that allows the drawing of road condition information bars based on KanziStudio to be independent of the secondary encoding and decoding of image data, the multiple creation of node2D inside kanzi, and the 30 frames per second image submission inside kanzi. It is highly cross-platform and strives to achieve the minimum resource consumption for the CPU and GPU.

[0051] The method for drawing the road condition information bar of the vehicle instrument provided in the embodiment of the present application can be applied to the terminal, can also be applied to the server side, and can also be software running in the terminal or the server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a vehicle terminal, etc.; the server side can be configured as an independent physical server, or a server cluster or a distributed system composed of multiple physical servers, and can also be configured as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application that implements the method for drawing the road condition information bar of the vehicle instrument, etc., but is not limited to the above forms.

[0052] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments, in which tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0053] It should be noted that in each specific implementation of the present application, when it is necessary to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first, and the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0054] Figure 1 A schematic diagram of a flow chart of a method for drawing a road condition information bar of a vehicle instrument provided in an embodiment of the present application. Figure 1 The method may include but is not limited to steps S101 to S105.

[0055] S101, obtaining current road congestion status data and current road congestion distance data;

[0056] S102, converting the current road congestion distance data into OPENGL vertex coordinate data, and converting the current road congestion status data into OPENGL vertex shading data;

[0057] S103, using the OPENGL vertex coordinate data and the OPENGL vertex shading data, drawing a thick line of a road condition information bar;

[0058] S104, generating texture data of the current road condition information bar according to the drawn thick line of the road condition information bar;

[0059] S105: Render the texture data of the current road condition information bar to display the current road condition information bar.

[0060] Specifically, this method uses the OpenGL graphics library to convert the road congestion status data and the congestion distance data into graphic data, and draws a road condition information bar, which is finally rendered and displayed on the vehicle instrument. First, it is necessary to obtain the congestion status (such as unblocked, light congestion, heavy congestion, etc.) and congestion distance (i.e., the length of the congested section) of the current road from the central control map application. The congestion distance data is converted into vertex coordinate data that can be converted into OpenGL, which defines the position and length of the road condition information bar on the screen. The congestion status data is converted into vertex shading data, which determines the color, transparency or other visual attributes of the road condition information bar to reflect different degrees of congestion. Using the drawing function of OpenGL, the thick line of the road condition information bar is drawn according to the obtained vertex coordinates and vertex shading data. After drawing the thick line of the road condition information bar, the system will further process this line to generate more complex texture data, including color gradients, patterns, etc., to more intuitively represent the congestion status. Finally, the generated road condition information bar texture data is rendered to the screen of the vehicle instrument, the texture data is passed to the OpenGL rendering pipeline, and the rendering command is called to draw the final image. After the rendering is completed, the user can see the current road congestion status information bar on the vehicle instrument. By obtaining the road congestion status and congestion distance data, using the OpenGL graphics library for data processing and drawing, the intuitive road condition information bar is finally displayed on the vehicle instrument, which not only improves the visualization of information, but also helps the driver to understand the current road conditions more quickly and make more informed driving decisions.

[0061] More specifically, this method uses the OpenGL library that Kanzi Engine relies on, and directly calls the rendering pipeline of the OpenGL library file for graphics drawing, breaking through the input of the vertex shader in KanziStudio that limits 8 vertex data, and performs plug-in processing on the shader drawing in the OpenGL library. After obtaining the available road condition data, it is converted into the corresponding vertex coordinates and passed into the vertex shader in OpenGL to enable the line segment drawing function of OpenGL for drawing. Here, the line segment drawing function is enabled instead of the graphics drawing function. In the kanzi window, the line segment can be stretched and presented as a strip without affecting its presentation. The line segment drawing function can further reduce the resource consumption occupied by OpenGL drawing. After the OpenGL drawing is successful, the texture data is generated through create2dTexture() and submitted to the kanzi window for rendering. The kanzi window only needs one node2d node to present the content.

[0062] In some embodiments, the step S103 specifically includes:

[0063] Draw a road condition information line segment using the OPENGL vertex coordinate data and the OPENGL vertex shading data;

[0064] The line segment of the road condition information bar is stretched to obtain a thick line of the road condition information bar.

[0065] Specifically, the system first obtains vertex coordinate data and vertex shading data. The vertex coordinate data defines the starting and ending positions of the line segment of the traffic information bar to ensure that the line segment can be correctly positioned on the screen; while the vertex shading data determines the visual attributes of the line segment such as color and transparency, so that it can reflect different road congestion states. The basic line segment of the traffic information bar is drawn using the drawing function of OpenGL. After the basic line segment is drawn, in order to make it more eye-catching and easy to observe, the system will stretch the line segment to turn it into a thick line. The stretching operation is achieved by adjusting the width of the line segment or applying a certain form of expansion algorithm. In OpenGL, the thick line effect can be simulated by setting line width parameters or using a specific shader program. The stretched thick line is not only more conspicuous, but also better represents the severity or length of road congestion, providing more intuitive information for the driver. By drawing thin lines and stretching them, the system can use OpenGL vertex coordinate data and vertex shading data to draw and process the line segment of the traffic information bar, and finally obtain a thick line of the traffic information bar that is both beautiful and practical.

[0066] In some embodiments, the step S103 specifically includes:

[0067] If the OPENGL vertex coordinate data exceeds the preset OPENGL vertex coordinate range, a vertex coordinate out-of-limit warning is output;

[0068] If the OPENGL vertex coordinate data does not exceed the preset OPENGL vertex coordinate range, the OPENGL vertex coordinate data and the OPENGL vertex shading data are used to draw a thick line of the road condition information bar.

[0069] Specifically, when the vertex data is wrong during the line segment drawing function of OpenGL, the OpenGL library will return a warning prompt. If a warning prompt is received, create2dTexture() will no longer be called to convert the wrong image data into texture data and submit it to the Kanzi window, thereby avoiding the situation where the road condition bar data is incorrect and causes the drawing program to crash or present an abnormal image display. Before starting to draw, the system will first check whether the OpenGL vertex coordinate data exceeds the preset OpenGL vertex coordinate range. The preset range is determined according to the resolution and size of the on-board instrument screen and the design requirements of the road condition information bar. If the vertex coordinate data exceeds the range, it means that the drawing position exceeds the boundary of the screen or does not meet the design expectations. The system will immediately output a vertex coordinate over-limit warning to remind the system that the data is abnormal and stop the subsequent processing of the invalid data. If the vertex coordinate data does not exceed the preset range, that is, the data is valid, then the system can continue to use these data and OpenGL vertex shading data to draw the thick line of the road condition information bar.

[0070] In some embodiments, the step S103 specifically includes:

[0071] If the OPENGL vertex coordinate data does not change according to the preset trend, a vertex coordinate out-of-bounds warning is output;

[0072] If the OPENGL vertex coordinate data changes according to a preset trend, a thick line of a road condition information bar is drawn using the OPENGL vertex coordinate data and the OPENGL vertex shading data.

[0073] Specifically, before starting to draw the thick line of the road condition information bar, the system will first check whether the OpenGL vertex coordinate data changes according to the preset trend. If the vertex coordinate data is folded back, it means that there is an abnormality or error in the data, and the change trend of the data does not meet expectations. The system will output a vertex coordinate out-of-bounds warning and stop the subsequent drawing and rendering of the erroneous data. If the vertex coordinate data changes according to the preset trend, that is, the data is valid and meets expectations, then the system can continue to use these data and OpenGL vertex shading data to draw the thick line of the road condition information bar. The system will call the OpenGL drawing function, pass the vertex coordinates and shading data to the graphics processing unit (GPU), and the GPU will complete the final drawing work. By introducing the check of the change trend of the OpenGL vertex coordinate data in step S103, the accuracy and consistency of the data can be further ensured. This helps to avoid drawing errors, improve the visualization of information, and enhance the robustness and reliability of the system.

[0074] In some embodiments, the step S101 specifically includes:

[0075] Obtain current road congestion status data and current road congestion distance data;

[0076] Obtain the historical road congestion status data and historical road congestion distance data corresponding to the previous frame rendering;

[0077] If the current road congestion state data is consistent with the historical road congestion state data, and the current road congestion distance data is consistent with the historical road congestion distance data, the current road congestion state data and the current road congestion distance data are discarded.

[0078] Specifically, the system will first obtain the current road congestion status data and congestion distance data from the central control map application. At the same time, the system will obtain the historical road congestion status data and historical road congestion distance data corresponding to the previous frame rendering. Next, the system will compare the consistency of the currently acquired data with the historical data. Specifically, it will check whether the current road congestion status data is consistent with the historical road congestion status data, and whether the current road congestion distance data is consistent with the historical road congestion distance data. If the current data is exactly the same as the historical data, the system may think that there is no need to process the data again because they do not provide any new information. In this case, the system will discard the currently acquired road congestion status data and congestion distance data to avoid unnecessary calculation and resource consumption. This strategy helps optimize the performance of the system, especially when the data changes infrequently or the system resources are limited. If the current data is inconsistent with the historical data, the system will retain the data and continue with the subsequent drawing steps.

[0079] By introducing historical data comparison and consistency check in step S101, the system can process road congestion status data and congestion distance data more intelligently, avoid unnecessary calculation and resource consumption, and improve system performance and efficiency. At the same time, when road conditions change, the system can also update the road condition information bar in time to provide drivers with accurate and useful navigation information.

[0080] In some embodiments, the step S105 specifically includes:

[0081] Get the texture data of the historical traffic information bar corresponding to the previous frame rendering;

[0082] If the texture data of the historical traffic information bar is consistent with the texture data of the current traffic information bar, obtaining the historical traffic information bar corresponding to the previous frame rendering, and displaying the historical traffic information bar;

[0083] If the texture data of the historical road condition information bar is inconsistent with the texture data of the current road condition information bar, the texture data of the current road condition information bar is rendered to display the current road condition information bar.

[0084] Specifically, by introducing the comparison and consistency check of the texture data of the historical traffic information bar, the system can intelligently decide whether to directly display the historical traffic information bar or render the current traffic information bar. This strategy helps to optimize the rendering process, reduce unnecessary calculations and resource consumption, and improve the performance and efficiency of the system. At the same time, when the traffic information changes, the system can also update the traffic information bar in a timely manner to ensure that the driver can obtain accurate and useful navigation information. The system first obtains the texture data of the historical traffic information bar corresponding to the previous frame rendering from the storage or cache. Then, the system compares the consistency of the texture data of the historical traffic information bar with the texture data of the current traffic information bar. If the two are exactly the same, it means that there is no visual change in the current traffic information bar, so there is no need to re-render. If the texture data of the historical traffic information bar is consistent with the texture data of the current traffic information bar, the system will directly obtain the historical traffic information bar corresponding to the previous frame rendering and display it on the screen. This approach can save rendering time and computing resources and improve the performance of the system. If the texture data of the historical traffic information bar is inconsistent with the texture data of the current traffic information bar, the system needs to render the texture data of the current traffic information bar. After the rendering is completed, the system will display the current traffic information bar to update the traffic display on the vehicle instrument.

[0085] Figure 2 A schematic diagram of the structure of a vehicle-mounted instrument road condition information bar drawing device provided in an embodiment of the present application, the vehicle-mounted instrument road condition information bar drawing device comprising:

[0086] The road condition acquisition module 201 is used to acquire current road congestion status data and current road congestion distance data;

[0087] A vertex conversion module 202, used to convert the current road congestion distance data into OPENGL vertex coordinate data, and convert the current road congestion status data into OPENGL vertex shading data;

[0088] A road condition drawing module 203 is used to draw a thick line of a road condition information bar using the OPENGL vertex coordinate data and the OPENGL vertex shading data;

[0089] The texture generating module 204 is used to generate the texture data of the current road condition information strip according to the drawn thick line of the road condition information strip;

[0090] The traffic condition display module 205 is used to render the texture data of the current traffic condition information bar and display the current traffic condition information bar.

[0091] The specific implementation of the vehicle-mounted instrument road condition information bar drawing device is basically the same as the specific implementation of the vehicle-mounted instrument road condition information bar drawing method described above, and will not be repeated here.

[0092] The embodiment of the present application also provides an electronic device, the electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the above-mentioned vehicle instrument road condition information bar drawing method when executing the computer program. The electronic device can be any intelligent terminal including a tablet computer, a vehicle computer, etc.

[0093] See also Figure 3 , Figure 3 The hardware structure of an electronic device of another embodiment is illustrated, and the electronic device includes:

[0094] The processor 301 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0095] The memory 302 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 302 can store an operating system and other applications. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 302, and the processor 301 calls and executes the method for drawing the vehicle instrument road condition information bar in the embodiment of this application;

[0096] Input / output interface 303, used to implement information input and output;

[0097] The communication interface 304 is used to realize the communication interaction between the device and other devices. The communication can be realized through a wired manner (such as USB, network cable, etc.) or a wireless manner (such as mobile network, WIFI, Bluetooth, etc.);

[0098] A bus 305 that transmits information between the various components of the device (e.g., the processor 301, the memory 302, the input / output interface 303, and the communication interface 304);

[0099] The processor 301 , the memory 302 , the input / output interface 303 and the communication interface 304 are connected to each other in communication within the device via the bus 305 .

[0100] An embodiment of the present application further provides a vehicle, which includes the above-mentioned vehicle-mounted instrument road condition information bar drawing device or the above-mentioned electronic device.

[0101] The embodiment of the present application also provides a computer program product, including a computer program, which implements the above-mentioned method for drawing a road condition information bar of an on-board instrument when executed by a processor.

[0102] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0103] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0104] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0105] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0106] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0107] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0108] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0109] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0110] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0111] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0112] The preferred embodiments of the present application are described above with reference to the accompanying drawings, but the scope of the rights of the present application is not limited thereto. Any modification, equivalent substitution and improvement made by those skilled in the art without departing from the scope and essence of the present application should be within the scope of the rights of the present application.

Claims

1. A method for drawing a road condition information bar of a vehicle-mounted instrument, characterized in that: The method comprises: Obtain current road congestion status data and current road congestion distance data; Convert the current road congestion distance data into OPENGL vertex coordinate data, and convert the current road congestion status data into OPENGL vertex shading data; Using the OPENGL vertex coordinate data and the OPENGL vertex shading data, drawing a thick line of a road condition information bar; Generate current road condition information bar texture data according to the drawn road condition information bar thick line; The texture data of the current traffic condition information bar is rendered to display the current traffic condition information bar.

2. The method for drawing a road condition information bar of an on-vehicle instrument according to claim 1, characterized in that: The step of drawing a thick line of the road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data specifically includes: Draw a road condition information line segment using the OPENGL vertex coordinate data and the OPENGL vertex shading data; The line segment of the road condition information bar is stretched to obtain a thick line of the road condition information bar.

3. The method for drawing a road condition information bar of an on-vehicle instrument according to claim 1, characterized in that: The step of drawing a thick line of the road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data specifically includes: If the OPENGL vertex coordinate data exceeds the preset OPENGL vertex coordinate range, a vertex coordinate out-of-limit warning is output; If the OPENGL vertex coordinate data does not exceed the preset OPENGL vertex coordinate range, the OPENGL vertex coordinate data and the OPENGL vertex shading data are used to draw a thick line of the road condition information bar.

4. The method for drawing a road condition information bar of an on-vehicle instrument according to claim 1, characterized in that: The step of drawing a thick line of the road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data specifically includes: If the OPENGL vertex coordinate data does not change according to the preset trend, a vertex coordinate out-of-bounds warning is output; If the OPENGL vertex coordinate data changes according to a preset trend, a thick line of a road condition information bar is drawn using the OPENGL vertex coordinate data and the OPENGL vertex shading data.

5. The method for drawing a road condition information bar of an on-vehicle instrument according to claim 1, characterized in that: The step of obtaining current road congestion status data and current road congestion distance data specifically includes: Obtain current road congestion status data and current road congestion distance data; Obtain the historical road congestion status data and historical road congestion distance data corresponding to the previous frame rendering; If the current road congestion state data is consistent with the historical road congestion state data, and the current road congestion distance data is consistent with the historical road congestion distance data, the current road congestion state data and the current road congestion distance data are discarded.

6. The method for drawing a road condition information bar of an on-vehicle instrument according to claim 1, characterized in that: The step of rendering the texture data of the current traffic condition information bar to display the current traffic condition information bar specifically includes: Get the texture data of the historical traffic information bar corresponding to the previous frame rendering; If the texture data of the historical traffic information bar is consistent with the texture data of the current traffic information bar, obtaining the historical traffic information bar corresponding to the previous frame rendering, and displaying the historical traffic information bar; If the texture data of the historical road condition information bar is inconsistent with the texture data of the current road condition information bar, the texture data of the current road condition information bar is rendered to display the current road condition information bar.

7. A device for drawing a road condition information bar on a vehicle instrument, characterized in that: The device comprises: A road condition acquisition module is used to obtain current road congestion status data and current road congestion distance data; A vertex conversion module, used to convert the current road congestion distance data into OPENGL vertex coordinate data, and convert the current road congestion status data into OPENGL vertex shading data; A road condition drawing module, used for drawing a thick line of a road condition information bar by using the OPENGL vertex coordinate data and the OPENGL vertex shading data; A texture generation module, used for generating texture data of the current road condition information strip according to the drawn thick line of the road condition information strip; The traffic condition display module is used to render the texture data of the current traffic condition information bar and display the current traffic condition information bar.

8. An electronic device, characterized in that: The electronic device comprises a memory and a processor, the memory stores a computer program, and the processor implements the method for drawing a road condition information bar of an on-vehicle instrument as claimed in any one of claims 1 to 6 when executing the computer program.

9. A vehicle, characterized in that: The vehicle includes the on-vehicle instrument road condition information bar drawing device as claimed in claim 7 or the electronic device as claimed in claim 8.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method for drawing a road condition information bar of an on-vehicle instrument as described in any one of claims 1 to 6 is implemented.

Images