Script translation method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a script translation method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring an initial script; the initial script is generated when a source platform executes a graphic rendering task; identifying a graphics library used by the initial script to obtain a graphics library type; translating the initial script based on the graphics library type to obtain a target script; the target script is used for executing the graphic rendering task on a target platform. By adopting the method, the initial script can be efficiently translated on different platforms.

Description

Technical Field

[0001] The present application relates to the technical field of computer graphics, and in particular to a script translation method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Art

[0002] OpenGL (Open Graphics Library) is a mature, cross-platform computer graphics application programming interface (API). OpenGL focuses on graphics rendering, meaning that the core OpenGL API library does not provide an interface to a windowing system. Interaction with the windowing system is handled by other libraries. This separation allows OpenGL to be used across various platforms and environments, without being restricted to a specific windowing system.

[0003] The script of an OpenGL application is a data package. In order to display the scene drawn by OpenGL on the computer screen, the current mainstream window systems (X Window, Microsoft Windows, Mac OS) all provide extension libraries for connecting to OpenGL. The main goal of these extension libraries is to realize the conversion between OpenGL graphics and the corresponding system window screen.

[0004] However, since the script contains not only the core rendering library functions of OpenGL, but also the window library functions unique to the window system, an ordinary script player can only play the script on the application's running platform. Summary of the Invention

[0005] Based on this, it is necessary to provide a script translation method, device, computer equipment, computer-readable storage medium and computer program product that can efficiently translate the initial script on different platforms to address the above technical problems.

[0006] In a first aspect, the present application provides a script translation method, comprising:

[0007] Obtaining an initial script; the initial script is generated by the source platform when executing a graphics rendering task;

[0008] Identify the graphics library used by the initial script to obtain the graphics library type;

[0009] Based on the graphics library type, the initial script is translated to obtain a target script; the target script is used to execute the graphics rendering task on a target platform.

[0010] In one embodiment, the above-mentioned translating the initial script based on the graphics library type to obtain the target script includes:

[0011] Based on the graphics library type, translating the initial script from the graphics library call of the source platform to the graphics library call of the target platform;

[0012] The translated script called by the graphics library is used as the target script.

[0013] In one embodiment, translating the initial script from the graphics library call of the source platform to the graphics library call of the target platform based on the graphics library type includes:

[0014] Identifying a call rendering command in the initial script;

[0015] The rendering call command is translated in combination with the graphics library type and the corresponding implementation method of the rendering call command on the target platform.

[0016] In one embodiment, the above-mentioned translation of the rendering command in combination with the graphics library type and the corresponding implementation of the rendering command on the target platform includes:

[0017] Parsing the initial script to obtain display requirements;

[0018] According to the graphics library type, matching the display requirements with the target platform to obtain a display configuration;

[0019] Through the implementation method, a rendering environment is created based on the display configuration, and the rendering environment is activated to obtain the target script.

[0020] In one embodiment, the display requirements include open display requirements and embedded display requirements; the open display requirements are attribute lists; the embedded display requirements are initial pixel format requirements;

[0021] The step of matching the display requirements with the target platform according to the graphics library type to obtain the display configuration includes:

[0022] When the graphics library type is an embedded graphics library, matching the embedded display requirement with a target pixel format requirement to obtain an embedded display configuration; the target pixel format requirement is obtained from the target platform through a pixel selection function;

[0023] When the graphics library type is an open graphics library, the display requirement embedded display requirement is automatically matched with the display capability of the target platform to obtain an open display configuration.

[0024] In one embodiment, after obtaining the target script, the following steps are included:

[0025] Execute the target script to render and obtain the rendering result;

[0026] Switching the rendering result from the back buffer to the front buffer;

[0027] The rendering result in the front buffer is displayed in a target window of the target platform.

[0028] In a second aspect, the present application further provides a script translation device, comprising:

[0029] An acquisition module is used to acquire an initial script; the initial script is generated by the source platform when performing a graphics rendering task;

[0030] An identification module, configured to identify the graphics library used by the initial script and obtain the type of the graphics library;

[0031] A translation module is used to translate the initial script based on the graphics library type to obtain a target script; the target script is used to execute the graphics rendering task on a target platform.

[0032] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method in any one of the above embodiments when executing the computer program.

[0033] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method in any one of the above embodiments when the computer program is executed by a processor.

[0034] In a fifth aspect, the present application also provides a computer program product, comprising a computer program, which implements the steps of the method in any one of the above embodiments when executed by a processor.

[0035] The above-mentioned script translation method, apparatus, computer device, computer-readable storage medium and computer program product first obtain an initial script, identify the graphics library therein and determine the type of graphics library, and then translate the initial script into a target script that can be directly executed on the target platform according to the type, thereby achieving automatic adaptation and seamless migration of the source platform rendering logic between different platforms, which not only effectively avoids the tedious operations of repeated development and manual adjustment of window system interfaces between platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0037] Figure 1 Schematic diagram of an OpenGL window extension library on various operating systems in one embodiment;

[0038] Figure 2 Schematic diagram of a script translation method according to an embodiment;

[0039] Figure 3 A schematic diagram of an OpenGL application rendering process in one embodiment;

[0040] Figure 4 This is a workflow diagram of a translator using GLTranslator according to another embodiment;

[0041] Figure 5 A schematic diagram of the steps of translation performed by the GLX translation module in one embodiment;

[0042] Figure 6 This is a comparison diagram of GLX translation modules;

[0043] Figure 7 A schematic diagram of the steps of translation performed by an EGL translation module in one embodiment;

[0044] Figure 8 This is a comparison diagram of the EGL translation module;

[0045] Figure 9 is a structural block diagram of a script translation device in one embodiment;

[0046] Figure 10 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0048] As a cross-platform 3D graphics rendering API, OpenGL doesn't directly provide window creation and management functionality. Different operating systems use different windowing systems (such as the Windows windowing system, Linux's X Window or EGL environment, and macOS's Cocoa). To display OpenGL-rendered content in a window on a specific operating system, you need to use the corresponding extension library to connect the OpenGL context to the platform's windowing system interface.

[0049] Combine Figure 1 As shown, Figure 1 Figure 1 is a schematic diagram of the OpenGL window extension library on various operating systems in one embodiment. On Windows platforms, the WGL library is used as a bridge between OpenGL and the window; on Linux platforms, the XWindow system uses the GLX library to facilitate communication between OpenGL and the XWindow system; and in Linux or Android environments, the EGL library is used to connect OpenGL to the window system.

[0050] For example, consider an initial script that includes OpenGL core rendering functions and platform-specific window library functions. For example, a Linux script might contain GLX or EGL-related function calls. When replaying the script on another operating system, such as Windows, cross-platform playback becomes difficult because Windows natively uses WGL, while the script itself calls GLX or EGL functions. This prevents direct execution of the Linux-specific window library function calls on Windows, resulting in inaccurate display of the rendered results.

[0051] Therefore, this application designs a GLTranslator to implement a script translation method. Its function is to dynamically translate calls to GLX or EGL library functions in these scripts into corresponding WGL function calls for the Windows platform, allowing OpenGL scripts originally recorded on the Linux platform to be successfully executed and rendered on the Windows platform. This means that even if the script contains window functions specific to the Linux platform, after translation by GLTranslator, the Windows script player PlayerKHR can still replay the rendered scene.

[0052] In one embodiment, Figure 2 As shown, a script translation method is provided. This embodiment uses the method applied to the GLTranslator translator as an example. In this embodiment, the method includes the following steps:

[0053] Step S202 , obtaining an initial script; the initial script is generated by the source platform when executing a graphics rendering task.

[0054] The initial script is a record data packet generated by the source platform when running an application using OpenGL for graphics rendering. This packet stores the complete call sequence of the application during the entire rendering process, including calls to the OpenGL core API, context management operations, creation and binding of shaders and texture resources, and platform-specific library function calls related to the window system. The source platform refers to the computing environment where the application initially runs and completes its graphics rendering process.

[0055] Step 204: Identify the graphics library used by the initial script to obtain the graphics library type.

[0056] After receiving the initial script, the GLTranslator needs to identify the graphics library used in the script. While OpenGL itself is cross-platform, the window system functions used with it vary by platform. Common window system libraries include GLX, EGL, and WGL. For example, rendering in the X Window System on Linux uses GLX functions, while EGL is used in certain environments such as Android and Linux, and WGL is commonly used on Windows.

[0057] Optionally, the suffix of the initial script can be identified to obtain the graphics library type of the initial script. If the initial script is generated using the GLX library under a Linux system, the window system-related API recorded therein must have the "GLX" prefix; if EGL is used, the function call must begin with "egl". After the GLTranslator translator analyzes the initial script and finds the corresponding function call characteristics, it can determine the graphics library type in the script. Because different platforms have different context creation, drawing buffer exchange, and event handling methods. Therefore, only after obtaining the window library type used by the source script can the GLTranslator translator perform the corresponding translation.

[0058] Step 206: Based on the graphics library type, the initial script is translated to obtain a target script; the target script is used to execute the graphics rendering task on the target platform.

[0059] The target platform refers to the environment where the script can be directly run and the rendering results can be displayed after the script is finally translated. In actual applications, the target platform can be a Windows system or other operating system with a corresponding OpenGL environment and window system interface.

[0060] During the translation process, the GLTranslator translator does not make substantial changes to the OpenGL core API calls, because the core functions of OpenGL itself remain basically the same across different platforms. This means that core operations such as drawing instructions, shader compilation and linking, texture and buffer object creation and binding can be reproduced as is on the target platform. The only functions that the GLTranslator translator needs to adjust are those involving window system interactions and some context configuration data that may need to be reorganized for the target platform. In this way, the GLTranslator translator can generate a target script that is logically the same as the initial script, but in which platform interface calls have been mapped to functions available on the target platform.

[0061] After translation, the target script can be directly loaded and executed on the target platform. The script player can then run this target script on the target platform, reproducing the scene drawn by the original application on the source platform. Because all core OpenGL operations remain unchanged, this replay process achieves highly consistent rendering results with the original runtime environment.

[0062] In the above script translation method, the initial script is first obtained, the graphics library therein is identified and the type of graphics library is determined, and then the initial script is translated into a target script that can be directly executed on the target platform according to the type, thereby realizing automatic adaptation and seamless migration of the source platform rendering logic between different platforms, which not only effectively avoids the tedious operations of repeated development and manual adjustment of window system interfaces between platforms.

[0063] Furthermore, the above-mentioned translation of the initial script based on the graphics library type to obtain the target script includes: translating the initial script from the graphics library call of the source platform to the graphics library call of the target platform based on the graphics library type; and using the script after the graphics library call translation as the target script.

[0064] Optionally, the core of the translation process is to map the rendering commands of the source platform to function calls that can be recognized and correctly executed by the target platform. For example, if the target platform is a Windows system, the corresponding window and OpenGL context interface functions are WGL series functions. For example, if there are a large number of GLX function calls in the source script, then after translation, these functions will be replaced with corresponding WGL calls. At the same time, since the context creation and pixel format setting methods of different platforms may not be completely equivalent, the GLTranslator translator also needs to adjust the parameters and return values according to the technical requirements of the target platform to ensure that the final generated target script can correctly initialize the OpenGL context on the target platform, select the appropriate pixel format and execute drawing instructions normally.

[0065] Furthermore, the translation process is based on the graphics library type. This is because different graphics library types have differences in the image rendering process. Therefore, the GLTranslator translator must select the correct mapping strategy based on the identified graphics library type.

[0066] Optionally, the GLTranslator translator may include translation modules corresponding to the graphics library types. For example, there are two types of graphics libraries, GLX and EGL. The GLTranslator translator includes two translation modules, GLX and EGL, which translate for different graphics library types respectively.

[0067] Optional, combined Figure 3 As shown, Figure 3 The figure is a schematic diagram of the rendering process of an OpenGL application in one embodiment, which includes four key steps: obtaining the environment, setting the pixel format, creating the rendering environment, activating the current rendering environment, and completing the drawing.

[0068] First, get the device environment and set the pixel format: The pixel format (PixelFormat) encapsulates a large amount of attribute information related to window characteristics. The application will find a matching pixel format according to rendering needs.

[0069] Next, create a rendering context: An application may have multiple windows. Before executing an OpenGL command, you need to specify a current rendering window, telling the driver which window to send the output to. This operation creates the current OpenGL rendering context. The rendering context is used to record the current settings and commands of the OpenGL application.

[0070] Next, the current rendering context is activated: a rendering context is created for each window, so a rendering context is associated with a specific window. In order for OpenGL commands to know which window they are servicing, each thread can only activate one rendering context at a time. When a rendering context is activated, it is called the current rendering context.

[0071] Finally, the drawing is completed and the back buffer data is synchronized to the window: When using a double-buffered pixel format, two surfaces of the same size as the window are allocated, called the front buffer and the back buffer. Double buffering allows the entire scene to be drawn into the back buffer without displaying the intermediate drawing results on the screen. After the drawing is completed, a buffer swap operation is performed and the back buffer is displayed, providing a smoother visual experience.

[0072] Furthermore, based on the graphics library type, the initial script is translated from the graphics library call of the source platform to the graphics library call of the target platform, including: identifying the call rendering command in the initial script; translating the call rendering command in combination with the graphics library type and the corresponding implementation method of the call rendering command on the target platform.

[0073] Combine Figure 3 As shown in the example, a graphics rendering task involves four key steps: obtaining the environment, setting the pixel format, creating the rendering environment, activating the current rendering environment, and completing the drawing. Therefore, the initialization script includes GLX or EGL function calls to perform these four steps. To correctly execute these scripts on the target platform, the GLTranslator must first identify these rendering commands in the initialization script and map them to the corresponding WGL function calls for the target platform.

[0074] Optionally, during the translation process, after determining the graphics library type, the initial code is input into different translation modules based on the library type. Each translation module needs to identify rendering calls in each initial script during the translation process. These rendering calls are those directly related to graphics context management, pixel format setting, buffer swapping, and other functions, such as glXChooseVisual (selecting a visualization function), glXCreateContext (creating a GLX context), eglCreateContext (creating an EGL context), and eglSwapBuffers (swapping EGL buffers). After identifying these rendering calls, each translation module translates the source platform's graphics library function calls into equivalent function calls on the target platform based on predefined mapping rules. For example, on Linux, glXMakeCurrent is commonly used to activate the current rendering context, binding the device context, window, and rendering context. The corresponding WGL window library function, wglMakeCurrent, is used to bind the device context and rendering context.

[0075] For example, combined Figure 4 , Figure 4 The following is a flowchart of the GLTranslator translator in one embodiment.

[0076] Step 1. Use the accompanying API tracker to capture the OpenGL application generation scripts for each system platform.

[0077] Step 2. The script of a Windows OpenGL application includes WGL window library functions and GL core API; the script of a Linux OpenGL application includes GLX window library functions and GL core API, or EGL window library functions and GL core API.

[0078] Step 3. The GLTranslator calls the GLX_WGL_Trans module and the EGL_WGL_Trans module to process the GLX type and EGL type scripts respectively, and translates them into WGL type scripts.

[0079] Step 4. Input the translated WGL script into the script player PlayerKHR for rendering on the Windows platform.

[0080] Furthermore, in one embodiment, the above-mentioned combination of the graphics library type and the corresponding implementation method of the rendering command on the target platform translates the rendering command, including: parsing the initial script to obtain display requirements; matching the display requirements with the target platform according to the graphics library type to obtain the display configuration; creating a rendering environment based on the display configuration through the implementation method, and activating the rendering environment to obtain the target script.

[0081] During the translation process, both the GLX and EGL translation modules parse the source script to derive the display requirements. These are the display device, pixel format, buffer mode, and context characteristics that the source application requires during graphics rendering. For example, the display requirements might include expectations for double buffering, a specific color depth, a depth buffer, and multisampling.

[0082] Afterwards, the GLX translation module and the EGL translation module respectively match the display requirements with the target platform to obtain the display configuration.

[0083] The GLX translation module automatically matches the open display requirements with the display capabilities of the target platform to obtain an open display configuration, wherein the open display requirements are a list of attributes.

[0084] Optionally, when the graphics library type is GLX, the GLX translation module automatically matches attribute lists with the target platform's display capabilities. These attribute lists describe the application's display configuration requirements on the source platform, such as color depth, support for double buffering, multisampling, and depth and stencil buffer specifications. Based on these attribute requirements, the GLX translation module uses corresponding functions to obtain open display requirements. Assuming the target platform is Windows, the best matching pixel format can be selected using ChoosePixelFormat (a pixel selection function) or wglChoosePixelFormatARB (a function that selects pixel formats through the WGL extension), and then applied to the device context (DC) using SetPixelFormat (a function that sets pixel formats). This process essentially automatically maps the requirements in the GLX attribute lists to available pixel formats and display features on the Windows platform, resulting in an open display configuration suitable for the target platform.

[0085] After automatically matching the display requirements with the target platform's display capabilities, the GLX translation module has obtained an open display configuration. Next, it needs to create a rendering environment based on this display configuration and activate the rendering environment, ultimately generating a target script that can be run directly on the target platform.

[0086] For example, the GLX translation module first obtains the necessary parameters from the matched open display configuration, such as the selected pixel format and the appropriate color, depth, and stencil buffer configurations. With this information, the GLX translation module uses wglCreateContext (a function that creates a WGL rendering context) to create an OpenGL rendering context on the target platform's Windows system, matching the previously set pixel format device context. After obtaining the rendering context, the GLX translation module also activates the rendering context, making it the active context for the current thread. This is typically accomplished by calling wglMakeCurrent (a function that makes the specified rendering context the current context). wglMakeCurrent binds the device context and rendering context together, allowing subsequent OpenGL commands to be executed correctly within that context, allowing drawing to the foreground or back buffer. This step can be considered a translation of the semantics of glXMakeCurrent or similar API calls in the source platform. By activating the current rendering context, the translation module ensures that the OpenGL core rendering command sequence recorded in the initial script can be correctly executed within the target platform's graphics environment.

[0087] Among them, the EGL translation module matches the embedded display requirements with the target pixel format requirements to obtain the embedded display configuration; the target pixel format requirements are obtained from the target platform through the pixel selection function; among them, the embedded display requirements are the initial pixel format requirements.

[0088] When the graphics library type is EGL, the EGL translation module obtains a set of available pixel format requirements from the target platform through pixel selection functions such as ChoosePixelFormat or corresponding extension functions such as wglChoosePixelFormatARB. During this process, the EGL translation module compares the initial pixel format requirements item by item, selects the pixel format description that most closely matches the source requirements, and maps it to the embedded display configuration on the target platform. This mapping process may require parameter adjustments and adaptation to meet the specific restrictions and requirements of the Windows device context (DC).

[0089] After automatically matching the embedded display requirements with the target platform's display capabilities, the EGL translation module has obtained the embedded display configuration. Next, the EGL translation module needs to create a rendering environment on the target platform based on the embedded display configuration and activate it, ultimately generating a target script that can be directly executed on the target platform.

[0090] For example, the process of creating and activating a rendering context is as follows: The EGL translation module first applies the successfully matched embedded display configuration to the Windows system's device context, setting the appropriate pixel format for the device context using SetPixelFormat (a function that sets the pixel format). After completing this step, the translation module calls wglCreateContext to create an OpenGL rendering context for the device context with the set pixel format. This rendering context hosts the execution environment for OpenGL drawing instructions and is functionally equivalent to the source platform's EGL context.

[0091] After obtaining a rendering context, the EGL translation module binds it to the corresponding device context using the wglMakeCurrent function and activates the rendering environment. Once activated, subsequent OpenGL drawing commands can be executed normally within the context. This is similar to activating an EGL context using eglMakeCurrent (which makes the specified EGL context the current context) on the source platform, but is performed in the Windows / WGL environment.

[0092] After the rendering environment is successfully created and activated, the EGL translation module outputs the translation result, that is, the script that has mapped EGL related calls to WGL call sequences, as the target script.

[0093] In one embodiment, after obtaining the target script, the method includes: executing the target script for rendering to obtain a rendering result; switching the rendering result from the back buffer to the foreground buffer; and displaying the rendering result in the foreground buffer in a target window of the target platform.

[0094] First, the rendering command sequence is executed using the target script. The OpenGL Core Drawing commands in the target script are executed sequentially within the created and activated rendering context, completing the rendering of the graphics scene in the back buffer. At this point, all shader execution, texture and buffer data processing, geometry transformation, and rasterization have already been completed in the back buffer.

[0095] Next, the rendering results need to be swapped from the back buffer to the front buffer. Target platforms typically use a double buffering mechanism: a front buffer visible to the user in real time, and a back buffer where rendering is currently taking place. Image data in the back buffer is swapped with the front buffer, allowing the newly rendered image to appear instantly in the user's field of view. Simultaneously, older data from the front buffer is fed into the back buffer for use in the next frame, achieving smooth animations and visual transitions.

[0096] Finally, after the buffer swap is complete, the rendering results in the front buffer are displayed in the target window on the target platform. What the user sees in the target platform's desktop window is the rendering behavior recorded when the initial script was executed on the source platform, translated and reproduced on the target platform.

[0097] For example, combined Figure 5 and Figure 6 As shown, Figure 5 FIG. 1 is a schematic diagram of the steps of translation performed by the GLX translation module in one embodiment. Figure 6 A comparison diagram of GLX translation modules.

[0098] Step 1. On Linux, use glXOpenDisplay (the function that opens the display) to obtain the device context and call the X window command to create a window.

[0099] [Step 1 GLX Translation] First create a Windows desktop window and obtain the device context DC from the window (the Windows system API is used here, not the WGL library function).

[0100] Step 2. To set the display configuration on Linux, you often use glXChooseFBConfig (a function that selects FBConfig) + glXGetFBConfigAttrib (a function that gets FBConfig attributes) + glXGetVisualFromFBConfig (a function that gets Visual from FBConfig) or directly use glXChooseVisual (a function that selects Visual). In the current device environment, get the matching display configuration based on the attribute list atttibList A parameter passed in.

[0101] [Step 2 GLX Translation] Adjust the attribute values in the attribute list attribList A to adapt to the Windows system (for example, the flag attribute), and obtain the display configuration from the device context DC (using the Windows system API here, not the WGL library function).

[0102] Step 3. Create a rendering environment on Linux, usually using glXCreateContext (a function that creates a GLX context), glXCreateNewContext (a function that creates a new GLX context), or glXCreateContextAttribsARB (a function that creates a GLX context through attributes). Use the display configuration obtained previously, or add the attribute list attribList B, to obtain a rendering environment from the device environment.

[0103] [Step 3 GLX Translation] Set the pixel format of the DC, and then use the WGL window library function wglCreateContext or glXCreateContextAttribsARB to obtain the rendering context from the device context DC according to the adjusted AttribList B.

[0104] Step 4. Activate the current rendering environment on Linux. glXMakeCurrent is often used to bind the device environment, window, and rendering environment to achieve activation.

[0105] [Step 4 GLX Translation] Use the WGL window library function wglMakeCurrent to bind the device context and rendering context to activate them.

[0106] Step 5. During the GL core API rendering phase, the script's API call sequence is strictly executed to complete the rendering. The GLX translation module does not need to do any processing.

[0107] Step 6. Use glXSwapBuffers (a function that swaps GLX buffers) on Linux to display the rendering results in the desktop window.

[0108] [Step 6 GLX Translation] Use wglSwapBuffers (a function for swapping WGL buffers) to display the rendering results to the desktop window.

[0109] Step 7. At this point, the GLX translation module helps PlayerKHR implement Linux GLX type script rendering on the window system.

[0110] It should be noted that, in this embodiment, after GLX is activated, the target script can be obtained. Steps 5-7 are the process of executing the target script.

[0111] For example, combined Figure 7 and Figure 8 As shown, Figure 7 A schematic diagram of the steps of translation performed by the EGL translation module in one embodiment is shown. Figure 8 A comparison diagram of EGL translation modules.

[0112] Step 1. On Linux, use eglGetDisplay (a function for getting EGL display) to get the device environment and initialize egl.

[0113] [Step 1 EGL Translation] Create a windows window and get the default device context DC from it (the windows system API is used here, not the WGL library function).

[0114] Step 2. Create a display window on Linux using the X window command to create a window + eglChooseConfig (a function for selecting an EGL configuration) + eglCreateWindowSurface (a function for creating an EGL window surface).

[0115] [Step 2 EGL translation] Adjust the attribute values in the attribute list attribList to adapt to the Windows system (for example, the flag flag attribute), use ChoosePixelFormat to obtain the display configuration from the device context DC, and set it to the window SetPixelFormat (the Windows system API is used here, not the WGL library function).

[0116] Step 3. Create a rendering environment on Linux, usually using eglCreateContext (a function that makes the EGL context the current context), using the display configuration obtained previously, or adding the attribute list attribList, to obtain a rendering environment from the device environment.

[0117] [Step 3 EGL translation] Use the WGL window library function wglCreateContext to obtain the rendering environment from the device context DC.

[0118] Step 4. Activate the current rendering environment on Linux. Usually, eglMakeCurrent (the function that swaps the EGL buffer) is used to bind the device environment, window, and rendering environment to activate it.

[0119] [Step 4 EGL translation] Use the WGL window library function wglMakeCurrent (the function for exchanging WGL buffers) to bind the device context and rendering context to activate them.

[0120] Step 5. During the GL core API rendering phase, the script's API call sequence is strictly executed to complete the rendering. The EGL_translation module does not need to do any processing.

[0121] Step 6. Use eglSwapBuffers on Linux to display the rendering results to the desktop window.

[0122] [Step 6 EGL Translation] Use wglSwapBuffers to display the rendering results to the desktop window.

[0123] Step 7. At this point, the EGL translation module helps PlayerKHR implement the rendering of Linux EGL type scripts on the window system.

[0124] Similarly, it should be noted that in this embodiment, after EGL is activated, the target script can be obtained. Steps 5-7 are the process of executing the target script.

[0125] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0126] Based on the same inventive concept, embodiments of the present application also provide a script translation device for implementing the aforementioned script translation method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations in one or more of the following script translation device embodiments can be found in the aforementioned limitations on the script translation method and will not be further elaborated here.

[0127] In an exemplary embodiment, Figure 9 As shown, a script translation device is provided, comprising: an acquisition module, an identification module and a translation module, wherein:

[0128] The acquisition module is used to obtain the initial script; the initial script is generated by the source platform when performing the graphics rendering task.

[0129] The identification module is used to identify the graphics library used by the initial script and obtain the graphics library type.

[0130] The translation module is used to translate the initial script based on the graphics library type to obtain the target script; the target script is used to perform graphics rendering tasks on the target platform.

[0131] In one embodiment, the translation module includes:

[0132] The call translation unit is used to translate the initial script from the graphics library call of the source platform to the graphics library call of the target platform based on the graphics library type.

[0133] The target script forming unit is used to call the translated script of the graphics library as the target script.

[0134] In one embodiment, the calling translation unit includes:

[0135] The command identification subunit is used to identify the call rendering command in the initial script.

[0136] The command translation subunit is used to translate the rendering command based on the graphics library type and the corresponding implementation method of the rendering command on the target platform.

[0137] In one embodiment, the command translation subunit further includes:

[0138] The parsing subunit is used to parse the initial script to obtain display requirements.

[0139] The matching subunit is used to match the display requirements with the target platform according to the graphics library type to obtain the display configuration.

[0140] The rendering subunit is used to create a rendering environment based on the display configuration through an implementation method, activate the rendering environment, and obtain a target script.

[0141] In one embodiment, the matching subunit includes:

[0142] The first matching subunit is used to match the embedded display requirement with the target pixel format requirement to obtain the embedded display configuration when the graphics library type is an embedded graphics library; the target pixel format requirement is obtained from the target platform through a pixel selection function.

[0143] The second matching subunit is used to automatically match the open display requirement with the display capability of the target platform to obtain an open display configuration when the graphics library type is an open graphics library.

[0144] Each module in the script translation device described above can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0145] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 10As shown. The computer device includes a processor, a memory, an input / output interface (I / O) and a communication interface. The processor, memory and input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store initial scripts. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a script translation method is implemented.

[0146] Those skilled in the art will understand that Figure 10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0147] In an exemplary embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps of the method in any one of the above embodiments when executing the computer program.

[0148] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method in any one of the above embodiments are implemented.

[0149] In one embodiment, a computer program product is provided, comprising a computer program, which implements the steps of the method in any one of the above embodiments when executed by a processor.

[0150] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0151] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0152] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A script translation method, characterized in that: The method comprises: Obtaining an initial script; the initial script is generated by the source platform when executing a graphics rendering task; Identify the graphics library used by the initial script to obtain the graphics library type; Based on the graphics library type, the initial script is translated to obtain a target script; the target script is used to execute the graphics rendering task on a target platform.

2. The method according to claim 1, characterized in that The step of translating the initial script based on the graphics library type to obtain a target script includes: Based on the graphics library type, translating the initial script from the graphics library call of the source platform to the graphics library call of the target platform; The translated script called by the graphics library is used as the target script.

3. The method according to claim 2, characterized in that The translating, based on the graphics library type, the initial script from the graphics library call of the source platform to the graphics library call of the target platform comprises: Identifying a call rendering command in the initial script; The rendering call command is translated in combination with the graphics library type and the corresponding implementation method of the rendering call command on the target platform.

4. The method according to claim 3, characterized in that The translating of the rendering command in combination with the graphics library type and the corresponding implementation of the rendering command on the target platform includes: Parsing the initial script to obtain display requirements; According to the graphics library type, matching the display requirements with the target platform to obtain a display configuration; Through the implementation method, a rendering environment is created based on the display configuration, and the rendering environment is activated to obtain the target script.

5. The method according to claim 4, characterized in that The display requirements include open display requirements and embedded display requirements; the open display requirements are attribute lists; the embedded display requirements are initial pixel format requirements; The step of matching the display requirements with the target platform according to the graphics library type to obtain the display configuration includes: When the graphics library type is an embedded graphics library, matching the embedded display requirement with the target pixel format requirement to obtain an embedded display configuration; The target pixel format requirement is obtained from the target platform through a pixel selection function; When the graphics library type is an open graphics library, the open display requirement is automatically matched with the display capability of the target platform to obtain an open display configuration.

6. The method according to claim 1, characterized in that After obtaining the target script, the method includes: Execute the target script to render and obtain the rendering result; Switching the rendering result from the back buffer to the front buffer; The rendering result in the front buffer is displayed in a target window of the target platform.

7. A script translation device, characterized in that: The device comprises: An acquisition module is used to acquire an initial script; the initial script is generated by the source platform when performing a graphics rendering task; An identification module, configured to identify the graphics library used by the initial script and obtain the type of the graphics library; A translation module is used to translate the initial script based on the graphics library type to obtain a target script; the target script is used to execute the graphics rendering task on a target platform.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images