A method and terminal for switching rendering modes

By setting up a bridging adapter in the rendering mode process and utilizing a shared memory mechanism, the network connection disconnection problem during the switching between 2D and 3D rendering modes was resolved, achieving seamless switching and resource optimization, and improving the user experience.

CN118377652BActive Publication Date: 2025-12-05FUJIAN TIANQUAN EDUCATION TECH LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410414560.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-04-08
Publication Date
2025-12-05
Estimated Expiration
2044-04-08

AI Technical Summary

Technical Problem

In existing technologies, switching between 2D and 3D rendering modes requires rebuilding the underlying SDK, which causes the network socket connection to be broken, affecting the product experience.

Method used

By setting a bridging adapter in the rendering mode process, a shared memory mechanism is used to seamlessly switch between 2D and 3D rendering modes, avoiding the rebuilding of the underlying SDK. The first adapter intercepts and transfers SDK instance data to shared memory, and the second adapter reads, parses and processes the data in shared memory.

Benefits of technology

It enables seamless switching between 2D and 3D rendering modes, avoids network connection drops, reduces CPU and memory consumption, and improves user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN118377652B_ABST
    Figure CN118377652B_ABST
Patent Text Reader

Abstract

The application discloses a method and a terminal for switching a rendering mode, a first adapter intercepts SDK instance data of a current rendering mode process in real time and stores the SDK instance data in shared memory; the first adapter is a bridge adapter of a rendering mode process corresponding to the SDK instance; when a second adapter detects a switching demand, the second adapter reads the SDK instance data in the shared memory, analyzes and processes the SDK instance data, and completes switching of the rendering mode; and the second adapter is a bridge adapter of another rendering mode process. According to the application, the bridge adapters are arranged in the rendering mode processes respectively, all interfaces and capabilities of the SDK are proxied by the bridge adapters when the rendering mode is switched, an independent data processing layer is established above the SDK of the rendering mode process, the software is allowed to be seamlessly switched between 2D and 3D rendering modes, the underlying SDK does not need to be initialized, and the situation that a socket connection is disconnected due to restarting of different rendering processes is avoided.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing, in particular to a method for switching rendering mode and a terminal. BACKGROUND

[0002] Generally, software is developed by using 2D rendering technology or based on 3D rendering technology, wherein 2D and 3D rendering are different in performance effect. In the prior art, general software can adopt a 2D and 3D fusion mode, but does not support direct switching from 2D rendering to 3D rendering mode. The reason is that the technical framework used by 2D and 3D is different, and direct switching cannot be performed. In the case that the 2D process needs to be switched to the 3D process, the 2D process needs to be exited and then started to the 3D process. In this process, the switching of the two processes is realized at the bottom of the software framework, but this scheme has the following disadvantages:

[0003] 1. The product experience is not good. The switching between 2D and 3D causes a short network socket connection to be disconnected. In the scene of network games, the business is represented as game disconnection. In the scene of audio and video, the socket connection at the bottom of the audio and video is disconnected, which is represented as instantaneous disconnection of voice or video calls, resulting in poor product experience.

[0004] 2. The entire technical framework of 2D and 3D is different, and the bottom SDK or code needs to be reinitialized, which causes unnecessary CPU and memory consumption. SUMMARY

[0005] The technical problem to be solved by the present application is to provide a method for switching rendering mode and a terminal, which solves the problem of reinitializing the bottom SDK and causing the network socket to be disconnected when switching.

[0006] In order to solve the above technical problems, the technical scheme adopted by the present application is:

[0007] A method for switching rendering mode, comprising the steps of:

[0008] S1, a first adapter intercepts SDK instance data of a current rendering mode process in real time and stores the SDK instance data in shared memory; the first adapter is a bridge adapter of the SDK instance corresponding to the rendering mode process;

[0009] S2, when a second adapter detects a switching requirement, the second adapter reads the SDK instance data in the shared memory and analyzes and processes the SDK instance data to complete the switching of the rendering mode; the second adapter is a bridge adapter of another rendering mode process.

[0010] In order to solve the above technical problems, another technical scheme adopted by the present application is:

[0011] A terminal for switching rendering modes, comprising a first adapter and a second adapter;

[0012] The first adapter comprises a first processor, a first memory, and a first computer program stored in the first memory and executable on the first processor;

[0013] The second adapter comprises a second processor, a second memory, and a second computer program stored in the second memory and executable on the second processor;

[0014] The first processor implements the following steps when executing the first computer program:

[0015] S1, the first adapter intercepts SDK instance data of a current rendering mode process in real time and stores the SDK instance data in shared memory; the first adapter is a bridge adapter of a rendering mode process corresponding to the SDK instance;

[0016] S2, when the second adapter detects a switching requirement, the second adapter reads the SDK instance data in the shared memory and parses and processes the SDK instance data to complete switching of the rendering mode; the second adapter is a bridge adapter of another rendering mode process.

[0017] The present application has the beneficial effect of providing a method and a terminal for switching rendering modes, by setting bridge adapters in rendering mode processes, when the rendering mode is switched, all interfaces and capabilities of the SDK are proxied by the bridge adapters, and data is transmitted between the adapters through shared memory, an independent data processing layer is established on the SDK of the rendering mode process, that is, by using the underlying shared memory mechanism, the software is allowed to be seamlessly switched between 2D and 3D rendering modes without initializing the underlying SDK, and the situation that the socket connection is disconnected due to the need to restart different rendering processes in the traditional method is avoided. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 A flowchart of a method for switching rendering modes in an embodiment of the present application;

[0019] Figure 2 A terminal for switching rendering modes in an embodiment of the present application Figure 1 ;

[0020] Figure 3 A terminal for switching rendering modes in an embodiment of the present application Figure 2 ;

[0021] REFERENCE NUMERALS:

[0022] 1. A terminal for switching rendering modes; 2. a first adapter;

[0023] 3、first processor; 4、first memory; 5、second adapter;

[0024] 6、second processor; 7、second memory. DETAILED DESCRIPTION

[0025] To make the technical content of the present application, the purposes achieved and effects clear, the following will be described in conjunction with the embodiments and the accompanying drawings.

[0026] Please refer to Figure 1 A method for switching rendering mode, comprising the steps of:

[0027] S1, the first adapter intercepts the SDK instance data of the current rendering mode process in real time and stores the SDK instance data in the shared memory; the first adapter is a bridge adapter of the rendering mode process corresponding to the SDK instance;

[0028] S2, when the second adapter detects the switching demand, reads the SDK instance data in the shared memory, and parses and processes the SDK instance data to complete the switching of the rendering mode; the second adapter is a bridge adapter of another rendering mode process.

[0029] From the above description, the beneficial effects of the present application are that by setting a bridge adapter in the rendering mode process, when the rendering mode is switched, all interfaces and capabilities of the SDK are proxied by the bridge adapter, and data is transmitted between the adapters through the shared memory, an independent data processing layer is established on the SDK of the rendering mode process, that is, by using the underlying shared memory mechanism, the software is allowed to be seamlessly switched between 2D and 3D rendering modes without initializing the underlying SDK, avoiding the situation that the socket connection is disconnected due to the need to restart different rendering processes in the traditional method.

[0030] It should be noted that the SDK is a set of development tools, which allows developers to create application software for specific software packages, software frameworks, hardware platforms, computer systems, game consoles, operating systems, etc., in the embodiments of the present application, the SDK module is the core shared by 2D and 3D processes, which provides business logic and interfaces, so that 2D and 3D rendering can run on the same business logic, realizing the unification of functions; wherein, the 2D rendering mode is realized by QT, and the 3D rendering mode is realized by Unreal.

[0031] Those skilled in the art can understand that the bridge adapter is connected to the SDK module and the actual 2D / 3D rendering process as an intermediary layer. It does not involve its own business logic, but is responsible for forwarding requests and data correctly from one process to another. In the embodiment of the application, it is mainly used to realize the bridging between different rendering modes, ensuring that different rendering processes (2D and 3D) can share the same SDK instance without repeated initialization, thereby maintaining data consistency and continuity. In the above steps, the first adapter is the bridge adapter of the rendering mode process corresponding to the SDK instance, that is, the first adapter is the adapter that establishes the SDK instance first. Assuming that the 2D process starts first and occupies the SDK to establish the instance, the first adapter is the adapter of the 2D process, and the second adapter is the adapter of the 3D process. Conversely, the first adapter is the adapter of the 3D process, and the second adapter is the adapter of the 2D process.

[0032] In the embodiment of the application, the step S1 specifically comprises the steps of:

[0033] S11, the first adapter intercepts the SDK instance data of the current rendering mode process and serializes the SDK instance data into a memory block;

[0034] S12, the first adapter writes the memory block to the shared memory;

[0035] The step S2 specifically comprises the steps of:

[0036] The second adapter reads the memory block in the shared memory and deserializes the memory block, and processes the request data obtained by deserialization.

[0037] As can be seen from the above description, the first adapter intercepts the SDK instance data and converts the original data into a memory block by using serialization, which facilitates transmission in the shared memory. The second adapter reads the memory block and deserializes the memory block to obtain the original request data, which is processed in the second adapter without rebuilding the underlying code of the SDK.

[0038] In the embodiment of the application, the step S2 further comprises the steps of:

[0039] When the second adapter detects that the request data is video frame data, the second adapter provides the video frame data to the corresponding rendering mode interface by using a preset callback function after processing.

[0040] As can be seen from the above description, once the video frame data is processed (e.g., received from a webcam and processed by the 3D adapter), the 3D adapter uses the callback function interface to immediately push the new video frame to the 3D interface. In this way, the user can see the latest picture, seamlessly switch between 2D and 3D modes, and quickly and effectively process and display real-time updated data.

[0041] In an embodiment of the present application, the step S2 is followed by a step S3:

[0042] The second adapter detects the request data, and when the request data needs to be processed by the rendering mode process corresponding to the original SDK instance, the second adapter stores the request data in the shared memory;

[0043] The first adapter reads the request data in the shared memory and calls the SDK to process the request data.

[0044] As can be seen from the above description, when the rendering mode is switched according to the steps S1 and S2, the SDK still maintains the instantiation of the original rendering mode. For this case, the second adapter forwards the process to the process of the instance owner (the rendering mode corresponding to the first adapter) for processing, avoiding the interruption of the network connection socket or causing data loss.

[0045] In an embodiment of the present application, the first adapter and the second adapter are both provided with a mirror interface of the SDK corresponding to the process.

[0046] As can be seen from the above description, the mirror interface of the SDK corresponding to the process is provided in the adapter, which can also be regarded as copying a copy of the interface identical to the SDK. Through the consistent interface, the original source code does not need to be intruded and modified during development. The advantage of this mechanism is that the adapter is an independent layer, which can be inserted into the adapter layer on the already implemented SDK 2D or 3D product, without affecting the existing process and business, and without the need to modify the original code. The interface of the adapter is consistent with the interface of the SDK, so that all interfaces and callback functions can be processed and forwarded through the adapter.

[0047] Please refer to Figures 2-3 A terminal 1 for switching rendering modes, comprising a first adapter 2 and a second adapter 5.

[0048] The first adapter 2 comprises a first processor 3, a first memory 4, and a first computer program stored in the first memory 4 and executable on the first processor 3.

[0049] The second adapter 5 comprises a second processor 6, a second memory 7, and a second computer program stored in the second memory 7 and executable on the second processor 6;

[0050] The first processor implements the following steps when executing the first computer program:

[0051] S1, the first adapter intercepts SDK instance data of a current rendering mode process and stores the SDK instance data in shared memory; the first adapter is a bridge adapter of a rendering mode process corresponding to the SDK instance;

[0052] The second processor implements the following steps when executing the second computer program:

[0053] S2, the second adapter reads the SDK instance data in the shared memory and parses and processes the SDK instance data; the second adapter is a bridge adapter of another rendering mode process.

[0054] The application provides a method and a terminal for switching a rendering mode, which are mainly used for seamlessly switching between 2D and 3D rendering modes, and will be specifically described below in combination with embodiments.

[0055] Please refer to Figure 1 In the embodiment one of the application,

[0056] A method for switching a rendering mode comprises the following steps:

[0057] S1, the first adapter intercepts SDK instance data of a current rendering mode process in real time and stores the SDK instance data in shared memory; the first adapter is a bridge adapter of a rendering mode process corresponding to the SDK instance;

[0058] S2, when the second adapter detects a switching requirement, the second adapter reads the SDK instance data in the shared memory and parses and processes the SDK instance data, thereby completing switching of the rendering mode; the second adapter is a bridge adapter of another rendering mode process.

[0059] That is, in the embodiment, by setting the bridge adapters in the rendering mode processes respectively, when the rendering mode is switched, all interfaces and capabilities of the SDK are proxied by the bridge adapters, and data is transmitted between the adapters through the shared memory, an independent data processing layer is established on the SDK of the rendering mode process, that is, by using the underlying shared memory mechanism, the software is allowed to be seamlessly switched between 2D and 3D rendering modes without initializing the underlying SDK, and the situation that the socket connection is disconnected due to restarting different rendering processes in the traditional method is avoided.

[0060] Please refer to Figure 1Embodiment two of the present application is:

[0061] On the basis of embodiment one, step S1 specifically comprises steps of:

[0062] S11, the first adapter intercepts the SDK instance data of the current rendering mode process and serializes the SDK instance data into a memory block;

[0063] S12, the first adapter writes the memory block to the shared memory;

[0064] Step S2 specifically comprises steps of:

[0065] The second adapter reads the memory block in the shared memory and deserializes the memory block, and processes the request data obtained by deserialization.

[0066] Step S2 further comprises steps of:

[0067] When the second adapter detects that the request data is video frame data, the second adapter provides the processed video frame data to the corresponding rendering mode interface using a preset callback function.

[0068] Specifically, as follows: assuming switching from 2D to 3D;

[0069] (1) The 2D process SDK sends video frame data to the first adapter (or the adapter intercepts the video frame data of the SDK)

[0070] (2) The first adapter of the 2D process serializes the video frame data into a memory block;

[0071] (3) The adapter of the 2D process writes the memory block to a shared memory;

[0072] (4) The second adapter of the 3D process reads the memory block in the shared memory;

[0073] (5) The second adapter deserializes the memory block and converts the memory data into video frame data;

[0074] (7) The 3D adapter calls a video frame data interface to the 3D interface using a simulation data callback function interface;

[0075] (8) The 3D interface obtains the updated video frame data and renders it to the 3D world.

[0076] Please refer to Figure 1 Embodiment three of the present application is:

[0077] On the basis of embodiment two, step S2 further comprises step S3:

[0078] The second adapter detects the requested data. When the requested data needs to be processed by the rendering mode process corresponding to the original SDK instance, the second adapter will transfer the requested data to shared memory.

[0079] The first adapter reads the requested data from the shared memory and calls the SDK to process the requested data.

[0080] For example, suppose the 2D to 3D switch was completed in steps S1 and S2. At this time, the SDK is an instance of a 2D process, that is, the first adapter matches the process of 2D rendering mode and the second adapter matches the process of 3D rendering mode.

[0081] When a request to turn the camera on or off is received, perform the following steps:

[0082] 1. First, the user has switched from 2D to 3D, and the current interface is 3D;

[0083] 2. Use functions that utilize the 3D interface, such as the button to open the camera;

[0084] 3. The 3D adapter receives a "request to open the camera button" and calls the camera function;

[0085] 4. The 3D adapter will serialize the function name and parameters of the function that opens the camera into memory;

[0086] 5. The 3D adapter writes the serialized memory block into shared memory;

[0087] 6. Changes in memory were detected in the 2D adapter;

[0088] 7. The 2D process adapter reads the changed memory block;

[0089] 8. The 2D process adapter deserializes memory to parse the function name and parameters for opening the camera.

[0090] 9. The 2D adapter will call the SDK within the 2D process to actually execute the function that opens the camera, passing in the correct parameters;

[0091] 10. Finally, the system camera was successfully turned on.

[0092] Please refer to Figures 2-3 Embodiment four of the present invention is as follows:

[0093] A terminal 1 for switching rendering mode, comprising a first adapter 2 and a second adapter 5; the first adapter 2 comprises a first processor 3, a first memory 4, and a first computer program stored in the first memory 4 and executable on the first processor 3; the second adapter 5 comprises a second processor 6, a second memory 7, and a second computer program stored in the second memory 7 and executable on the second processor 6; the steps in any one of the methods for switching rendering mode in embodiments one to three are implemented when the first processor executes the first computer program and the second processor executes the second computer program.

[0094] In conclusion, the application establishes an independent data processing layer on the SDK of the rendering mode process by setting the bridge adapter respectively, all interfaces and capabilities of the SDK are proxied by the bridge adapter when the rendering mode is switched, and data transmission is performed between the adapters through the shared memory, thus allowing the software to be seamlessly switched between the 2D and 3D rendering modes without initializing the underlying SDK, and avoiding the situation that the socket connection is disconnected due to the restart of different rendering processes in the traditional method.

[0095] The above description is only an embodiment of the application, and does not limit the patent scope of the application, and any equivalent transformation or direct or indirect application in the related technical field based on the content of the specification and drawings of the application is also included in the patent protection scope of the application.

Claims

1. A method of switching rendering modes, the method comprising: The method comprises the steps of: S1, the first adapter intercepts the SDK instance data of the current rendering mode process in real time and stores the SDK instance data in the shared memory; the first adapter is a bridge adapter of the rendering mode process corresponding to the SDK instance; S2, when the second adapter detects a switching requirement, the second adapter reads the SDK instance data in the shared memory, parses and processes the SDK instance data, and completes the switching of the rendering mode; the second adapter is a bridge adapter of another rendering mode process; The step S1 specifically comprises the steps of: S11, the first adapter intercepts the SDK instance data of the current rendering mode process and serializes the SDK instance data into a memory block; S12, the first adapter stores the memory block in the shared memory; The step S2 specifically comprises the steps of: The second adapter reads the memory block in the shared memory and deserializes the memory block, and processes the request data obtained by deserialization.

2. The method of claim 1, wherein: The step S2 further comprises the step of: When the second adapter detects that the request data is video frame data, the second adapter provides the processed video frame data to the corresponding rendering mode interface by using a preset callback function.

3. The method of claim 1, wherein: The step S2 further comprises the step S3: The second adapter detects the request data, and when the request data needs to be processed by the rendering mode process corresponding to the original SDK instance, the second adapter stores the request data in the shared memory; The first adapter reads the request data in the shared memory and calls the SDK to process the request data.

4. The method of claim 1, wherein: The first adapter and the second adapter are both provided with a mirror interface of the SDK corresponding to the process.

5. A terminal that switches a rendering mode, characterized by: The method comprises a first adapter and a second adapter; The first adapter comprises a first processor, a first memory, and a first computer program stored in the first memory and executable on the first processor; The second adapter comprises a second processor, a second memory, and a second computer program stored in the second memory and executable on the second processor; When the first processor executes the first computer program, the following steps are implemented: S1, the first adapter intercepts the SDK instance data of the current rendering mode process in real time and stores the SDK instance data in the shared memory; the first adapter is a bridge adapter of the rendering mode process corresponding to the SDK instance; When the second processor executes the second computer program, the following steps are implemented: S2, when the second adapter detects a switching requirement, the second adapter reads the SDK instance data in the shared memory, parses and processes the SDK instance data, and completes the switching of the rendering mode; the second adapter is a bridge adapter of another rendering mode process; The step S1 specifically comprises the steps of: S11, the first adapter intercepts the SDK instance data of the current rendering mode process and serializes the SDK instance data into a memory block; S12, the first adapter stores the memory block in the shared memory; The step S2 specifically comprises the steps of: The second adapter reads the memory block in the shared memory and deserializes the memory block, and processes the request data obtained by deserialization. The step S2 further comprises the step of: When the second adapter detects that the request data is video frame data, the second adapter provides the processed video frame data to the corresponding rendering mode interface by using a preset callback function.

6. The terminal of claim 5, wherein: The step S2 further comprises the steps of: When the second adapter detects that the request data is video frame data, the second adapter provides the video frame data to the corresponding rendering mode interface using a preset callback function.

7. The terminal of claim 5, wherein: When the second processor executes the second computer program, the step S2 further comprises a step S3: When the second adapter detects the request data, if the request data needs to be processed by the rendering mode process corresponding to the original SDK instance, the second adapter stores the request data in the shared memory; The first adapter reads the request data in the shared memory and calls the SDK to process the request data.

8. The terminal of claim 5, wherein: The first adapter and the second adapter are both provided with a mirror interface of the SDK corresponding to the process.

Citation Information

Patent Citations

  • Sprite graphics rendering system

    CN104823215A

  • Water surface rendering method, device and readable storage medium

    CN107886562A