Task execution method and task platform

Abstract

According to the task execution method and the task platform, the task execution method is applied to the task platform, the task platform comprises a task module and a rendering module, and the task execution method comprises the steps that the task module is called to execute key task logic of a target task, and a rendering agent is generated, the rendering agent comprises the type of the target object and target object data required for rendering the target object; a rendering module is called to execute rendering logic based on the type of the target object and the target object data, a target rendering instruction is generated, and the target rendering instruction is used for driving the rendering module to execute the target rendering task. The problems in the task execution process can be quickly and accurately traced, the task execution efficiency is effectively improved, and the method can be widely applied to digital culture product manufacturing software in the digital creative industry and the related technical field of digital culture creative software.

Description

Technical Field

[0001] This application relates to the field of digital creative industry technology, and in particular to a task execution method. This application also relates to a task platform, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In the technical field of digital cultural product creation software and digital cultural creative software, front-end rendering is often required when executing software product tasks. In this process, a design pattern that separates the logic thread and the RHI (Rendering Hardware Interface) thread is often adopted. The logic thread executes the task logic and generates an intermediate representation of the rendering instructions, while the RHI thread is responsible for recording and translating the intermediate representation into underlying rendering instructions. With this task execution architecture, if a problem occurs during task execution, locating the problem often requires tracing back to the underlying rendering instructions, making it difficult to pinpoint the rendering resource corresponding to the error. This makes it difficult to handle errors that occur during task execution, leading to reduced task execution efficiency. Summary of the Invention

[0003] In view of this, embodiments of this application provide a task execution method to address the technical deficiencies existing in the prior art. Embodiments of this application also provide a task platform, a computing device, a computer-readable storage medium, and a computer program product.

[0004] According to a first aspect of the embodiments of this application, a task execution method is provided, applied to a task platform, the task platform including a task module and a rendering module, the task execution method including: The task module is invoked to execute the key task logic of the target task and generate a rendering proxy. The rendering proxy includes the type of the target object and the target object data required to render the target object. The rendering module executes rendering logic based on the type and data of the target object, generating target rendering instructions. These instructions drive the rendering module to perform the target rendering task.

[0005] According to a second aspect of the embodiments of this application, a task platform is provided, comprising: The task module is configured to execute the critical task logic of the target task and generate a rendering proxy, wherein the rendering proxy includes the type of the target object and the target object data required to render the target object; The rendering module is configured to execute rendering logic based on the type and data of the target object, and generate target rendering instructions. These target rendering instructions are used to drive the rendering module to execute the target rendering task.

[0006] According to a third aspect of the embodiments of this application, a computing device is provided, including: a memory and a processor; The memory is used to store computer programs / instructions, and the processor is used to execute computer programs / instructions. When the computer program / instruction is executed by the processor, it implements the task execution method.

[0007] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores a computer program / instructions, which, when executed by a processor, implement a task execution method.

[0008] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program / instructions, which, when executed by a processor, implement a task execution method.

[0009] The optional embodiments of this specification provide a task execution method applied to a task platform. The task platform includes a task module and a rendering module. The task platform executes the key task logic of the target task by calling the task module, ultimately generating a rendering proxy that includes the type of the target object and the target object data required for rendering the target object. This allows the rendering module to independently and completely execute rendering logic based on the target object type and target object data in the rendering proxy, thereby generating target rendering instructions to drive the rendering module to execute the target rendering task. This provides a traceable logical context for the execution process of the rendering task. During backtracking, the target rendering instructions can be used to trace back to the rendered target object, and then to the key task logic that executed the target task. This allows for quick and accurate tracing of problems that occur during task execution, effectively improving task execution efficiency. Attached Figure Description

[0010] Figure 1 This is a flowchart of a task execution method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a task execution method applied to a digital cultural and creative software development scenario, provided by an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a task platform provided in one embodiment of this application; Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0011] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0012] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” used in one or more embodiments of this application and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.

[0013] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first.

[0014] First, the terminology used in one or more embodiments of the present invention will be explained.

[0015] Rendering is the process in computer graphics of converting 3D models or scene data into 2D images. Through a series of computational steps (including geometric transformations, lighting calculations, texture mapping, and pixel shading), it simulates realistic visual information and ultimately generates an image or frame that can be displayed.

[0016] The rendering thread is a dedicated thread in the operating system responsible for performing rendering tasks. It is usually part of the application's main thread or the graphics subsystem. Its main responsibilities are to receive scene data, call graphics interfaces, drive the processor to perform calculations, and ensure that image data is updated to the display device at the frame rate.

[0017] A thread pool is a resource management pattern in multithreaded programming. It pre-creates a set of reusable threads and allocates and executes asynchronous tasks on demand. The core components of a thread pool include a task queue, a thread manager, and a scheduling strategy, which can effectively reduce the overhead of frequently creating and destroying threads, thereby improving system concurrency performance and resource utilization.

[0018] A GPU (Graphics Processing Unit) is a microprocessor chip specifically designed for efficient and parallel processing of images, videos, graphics rendering, and massively parallel computing tasks. It is the core hardware in computers (especially personal computers, game consoles, and workstations) responsible for processing all visual output and converting data into the final image on the screen.

[0019] This application provides a task execution method. This application also relates to a task platform, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0020] To address situations where rendering errors during task execution cannot be traced back to specific upper-level business logic and resources, this manual creatively constructs an architecture for the task module and rendering module. Instead of directly generating rendering commands, the task module generates an intermediate data package called a rendering proxy, which explicitly specifies the type of object to be rendered and the required data. The rendering module then independently executes the rendering logic and generates the target rendering instructions based on the rendering proxy. This allows for rapid error localization when rendering errors occur, directly pinpointing which rendering proxy caused the problem, thereby improving the execution efficiency of digital cultural product creation software and digital cultural creative software tasks.

[0021] Figure 1 This is a flowchart of a task execution method provided in an embodiment of this application, which specifically includes the following steps: Step 102: Call the task module to execute the key task logic of the target task and generate a rendering proxy. The rendering proxy includes the type of the target object and the target object data required to render the target object.

[0022] A task module is a software unit or subsystem within a task platform responsible for performing calculations, decisions, and state management related to core business or application logic. Based on the calculation results of business logic, a task module can create corresponding rendering proxies of different types for different types of visual entities that need to be rendered. This transforms the task's intent (such as "release a fireball effect" or "update a UI (User Interface) list item") into a concrete, executable rendering description, thus establishing a clear division of responsibilities between logic and rendering. For example, a task module could be a physics module in a game engine that creates a rendering proxy for an "exploding particle system" based on character collision results; or it could be a view controller in a UI system that creates a rendering proxy for a "text-image blending element" for each item in a list based on data changes.

[0023] A rendering proxy is a structured data carrier or work order created by a task module to fully describe the rendering requirements of a visual object. It contains all the information needed to render the object (such as geometric data, material properties, spatial transformation information, etc.). Its core function is to encapsulate the rendering task into an independent unit containing a description of the object to be rendered and capable of flow, carrying the complete intent and data from business logic to specific rendering operations. This allows the rendering module to independently complete the rendering work based on the rendering proxy and provides direct evidence for troubleshooting. For example, a rendering proxy can be a data package containing model mesh references, material parameters, and a position matrix to describe a static scene object; alternatively, it can be a data structure describing water surface ripple parameters, reflection textures, and shader identifiers.

[0024] Key task logic refers to a series of core computational and decision-making processes performed by a task module to complete a specific objective task, determining the application state, object behavior, interaction rules, and the final expected visualization effects. It focuses on the deduction of business rules and state evolution, typically independent of the underlying graphics rendering details. For example, in a game, key task logic might calculate the damage range, hit detection, and list of hit targets for a skill release, as well as determine the enumeration of visual effects to be played (such as "explosion" or "freeze"). For example, in a UI system, key task logic might respond to a button click event, calculating the type of pop-up to open, the list of data to be displayed within the pop-up, and the display style for each data item.

[0025] A target object refers to the specific visual entity that needs to be ultimately displayed on an output device (such as a screen) by the rendering module. It is the direct target of the rendering operation. For example, a target object can be a character model, a weapon, or a skill effect particle in a game; for example, a target object can also be a button, a piece of text, or an image in a user interface.

[0026] The type of a target object is a classification identifier for the common rendering characteristics and behaviors of the target object. It defines "what" the object is, thereby determining which rendering workflow, shader program, or graphics resource the rendering module should use to process it. For example, the type of a target object can be "static mesh model", "skeleton animation model", "particle system", "2D sprite", or "text block".

[0027] The data of a target object refers to a specific set of parameter information necessary for rendering a particular target object. It defines the "specific appearance" of the object and is a concrete instantiation of the type. For example, for a target object of type "static mesh model", its data may include vertex buffer references, index buffer references, applied texture resource handles, and world transformation matrices; for example, for a target object of type "particle system", its data may include emitter positions, particle lifecycles, initial velocities, color gradient tables, etc.

[0028] The execution of critical task logic by the task module to generate a rendering proxy involves the task module parsing the abstract rendering intent through the execution of critical task logic and instantiating this intent into a structured rendering proxy carrying complete rendering data. One possible approach is a synchronous call, where the main thread or logic thread directly and synchronously calls the task module's interface, passing in the target task parameters. After execution, the task module directly returns the constructed rendering proxy object. Another possible approach is an event-driven approach: when the target task needs to be executed, a task event is published to an event bus; the task module, as a subscriber, receives the event, executes the critical task logic, and sends the generated rendering proxy as a new message to another queue for consumption by the rendering module.

[0029] In one implementation of this specification, within a game scene, the objective is for the player character to cast a fireball spell. The task module is invoked to execute critical task logic: calculating the spell's casting point, trajectory, and collision detection, and determining that an explosion hits an enemy at coordinates (10, 5, 0). Based on this logic, the task module generates a rendering proxy. In this proxy, the target object's type is specified as "particle system," and the target object's data includes the explosion center coordinates (10, 5, 0), the particle resource ID "FX_Fireball_Explosion," and the initial scaling factor of 2.0. This rendering proxy is passed to the rendering module, thereby driving the rendering module to draw the explosion effect at the specified location.

[0030] Furthermore, to generate more realistic explosion effects, the task module can also submit "explosion particle physics simulation" tasks (such as calculating initial explosion force, particle diffusion velocity, and the effects of gravity) to a worker thread pool for execution. A worker thread pool is a system component or resource pool in a task platform or computer system used to manage and schedule a series of background worker threads. Its core design purpose is to efficiently execute parallelizable and computationally intensive subtasks to optimize overall system performance and resource utilization. The worker thread pool receives computation tasks submitted from other modules in the system (such as the task module and rendering module) and dynamically allocates them to idle worker threads within the pool for execution. While the worker thread pool asynchronously calculates particle physics states, the task module continues to execute other logic. When the worker thread pool completes the calculation and returns the particle physics states (such as the initial velocity vector of each particle), the task module integrates these results with the collision results to generate a rendering proxy. In this proxy, the target object type is specified as "particle system," and the target object data includes the explosion center coordinates (10,5,0), the particle resource ID "FX_Fireball_Explosion," the initial scaling factor of 2.0, and particle physics state data obtained from the worker thread pool. This rendering proxy is passed to the rendering module, driving the rendering module to draw a dynamic explosion effect that conforms to the physical simulation at the specified location.

[0031] In one implementation of this specification, in a UI interface scenario, the target task is to "refresh the friend list". The task module (such as the UI logic controller) executes the key task logic: retrieves the latest online friend data from the social service and calculates that three items in the list need to be updated. Then, it generates a rendering proxy for each friend item that needs updating. For one friend item, the target object type is "complex UI element (containing avatar and text)", and the target object data includes the image resource URL (Uniform Resource Locator) of the friend's avatar, the string "Player A" of the friend's nickname, the online status identifier (green icon resource ID), and the position index of the item in the list. After receiving these proxies, the rendering module can independently complete the rendering update of the list items.

[0032] Step 102 serves to transform abstract business intent into a structured data carrier—the rendering proxy—by invoking the task module to execute critical business-related task logic. This transforms the abstract business intent into a structured data carrier that the rendering system can directly understand and execute. It not only clarifies the type of the target object to be rendered but also encapsulates the necessary target object data for rendering. This provides clear, self-contained input for the independent and accurate execution of subsequent rendering modules and lays a direct data foundation for tracing problems during task execution.

[0033] Step 104: Call the rendering module to execute rendering logic based on the target object's type and data, and generate target rendering instructions. The target rendering instructions are used to drive the rendering module to execute the target rendering task.

[0034] Rendering logic refers to the internal processing flow within the rendering module that executes a series of resource preparations, state settings, and command organization based on the rendering intent defined by the type and data of the target object received from the rendering proxy. Its role is to translate the abstract, platform-independent rendering description into a specific sequence of operations that can be recognized and executed by the underlying graphics API (Application Programming Interface) or rendering hardware. For example, rendering logic could be a process for a "static mesh model" type, executing the binding of vertex buffers, index buffers, textures, and shaders, and ultimately initiating a draw call; or, for a "particle system" type, executing the process of updating particle lifetimes, calculating particle positions, and invoking instantiation draw commands.

[0035] A target rendering instruction is a single or set of low-level commands generated by the rendering logic of the rendering module that directly drive the underlying graphics system to perform specific drawing operations. It is the final output of the entire rendering pipeline and directly corresponds to specific operations on the GPU (Graphics Processing Unit). For example, a target rendering instruction can be a "DrawIndexed" call command that instructs the GPU to draw a list of indexed triangles; alternatively, a target rendering instruction can be a sequence of commands that sets the rendering pipeline state (such as blending mode or depth testing).

[0036] Calling the rendering module to execute rendering logic based on the target object's type and data refers to scheduling the corresponding rendering component according to the type and data defined in the rendering proxy, driving it to execute specific processing flows, and ultimately generating executable rendering instructions. One possible approach is type dispatching, where the rendering module maintains a registry mapping different target object types to different processing functions. When a rendering proxy is received, the module looks up the corresponding processing function based on its type, passes the target object's data as a parameter, and that function executes the specific rendering logic. Another possible approach is data-driven: the rendering proxy itself or its data contains an identifier (such as a shader program ID or pipeline state ID). The rendering module uses this identifier to directly configure the rendering pipeline, and then uses the target object's data to fill the pipeline's constant buffer or vertex buffer, thereby executing the rendering logic.

[0037] Target rendering instructions are used to drive the rendering module to execute target rendering tasks. One option is immediate execution: after generating the target rendering instructions, the rendering logic immediately submits them to the graphics API command queue for execution through the current thread (such as the rendering thread). Another option is command list recording: the rendering logic records the generated target rendering instructions into a command list or command buffer. This command list can be submitted for execution later by the rendering thread, or it can be merged with other command lists and submitted in batches.

[0038] In one implementation of this specification, the rendering module receives a rendering proxy, where the target object is of type "particle system," and the target object's data includes the explosion center coordinates (10, 5, 0) and the particle resource ID "FX_Fireball_Explosion." The rendering module's rendering logic is invoked: First, it locates the submodule responsible for particle rendering based on the type "particle system"; then, the submodule loads the corresponding particle texture and shader based on the particle resource ID; next, it updates the GPU constant buffer of the particle emitter using the coordinate data; finally, the rendering logic generates a series of target rendering instructions, including setting the particle shader, binding the particle texture, setting the blending state, and a "DrawInstanced" instruction to initiate particle instantiation and drawing. These instructions are submitted to drive the GPU to draw the explosion effect.

[0039] In one implementation of this specification, the rendering module receives a rendering proxy for a target object of type "complex UI element," whose data includes an avatar URL, the text "Player A," and a position index. The rendering module's rendering logic is invoked: first, it distributes the task to the UI renderer based on the type; the UI renderer converts the text "Player A" into glyph vertex data and asynchronously loads the avatar texture; subsequently, it generates two sets of target rendering instructions: the first set of instructions is used to draw the text, including binding the font texture, setting the text shader, updating the vertex buffer containing the glyph vertex data, and calling the "Draw" command; the second set of instructions is used to draw the avatar, including binding the loaded avatar texture, setting the UI image shader, updating the position matrix, and calling another "Draw" command. These instructions together drive the screen to correctly display the friend entry.

[0040] In addition, to avoid blocking the recording of rendering commands, the rendering module submits the "particle state update" task (such as position calculation and collision detection for the next frame) to the worker thread pool. The rendering module can then continue processing other rendering proxies that do not depend on particle state. Once the worker thread pool has completed the particle state calculation and returned the results, the rendering module uses this latest state data, combined with other information from the rendering proxies (such as textures and shaders), to generate the final target rendering command (such as DrawInstanced).

[0041] Step 104 transforms the rendering agent carrying explicit intent and data into specific target rendering instructions that can be directly executed by the graphics hardware by executing rendering logic adapted to the type of the target object. Utilizing the structured context information (type and data) within the rendering agent, efficient and accurate conversion from rendering intent to hardware instructions is achieved. Since the generation of rendering instructions is directly related to the specific rendering agent and its contained target object information, when rendering output anomalies occur (such as texture errors or model misalignments), the system can quickly and accurately trace back from the problematic instruction to the specific rendering agent that generated it, and even to the source business logic that generated that agent. This simplifies the diagnosis and localization process of rendering problems, thereby improving the maintainability and efficiency of the entire task platform.

[0042] The optional embodiments of this specification provide a task execution method applied to a task platform. The task platform includes a task module and a rendering module. The task platform executes the key task logic of the target task by calling the task module, ultimately generating a rendering proxy that includes the type of the target object and the target object data required for rendering the target object. This allows the rendering module to independently and completely execute rendering logic based on the target object type and target object data in the rendering proxy, thereby generating target rendering instructions to drive the rendering module to execute the target rendering task. This provides a traceable logical context for the execution process of the rendering task. During backtracking, the target rendering instructions can be used to trace back to the rendered target object, and then to the key task logic that executed the target task. This allows for quick and accurate tracing when problems occur during task execution, thereby improving the execution efficiency of tasks in digital cultural product creation software and digital cultural creative software.

[0043] In existing technologies, the boundary between logic execution and proxy generation may be blurred, leading to unclear intermediate states of the execution result. This makes it difficult to independently verify, debug, or perform performance analysis on the logic calculation stage, and also results in unclear and unmodular rendering proxy generation logic. An optional embodiment of this specification provides a method to solve the above problems. Specifically, step 102 includes the following steps: Call the task module to execute the key task logic of the target task and obtain the execution result of the current frame; A rendering proxy is generated based on the execution result of the current frame.

[0044] The execution result of the current frame refers to the set of states, data, and decision conclusions directly related to the desired visualization effect, generated by the task module after completing the key task logic of the target task within a specific time slice (usually corresponding to one screen refresh cycle, i.e., "one frame"). As the output of the key task logic, the execution result of the current frame encapsulates the final state of the business logic operation within that frame. It serves as the intermediate data representation connecting logical calculation and visualization, providing direct and accurate input for generating specific rendering proxies. For example, the execution result of the current frame could be the calculated 3D coordinates of a skill explosion point, a list of hit targets, and the identifier of the special effect to be played; for example, the execution result of the current frame could also be updated friend list data and its metadata obtained from a network service and required to be displayed in this frame.

[0045] Calling the task module to execute the key task logic of the target task and obtain the execution result of the current frame means that the task module transforms the abstract task intent into a structured execution result that guides the visualization of the current frame by executing the key task logic of the target task. One possible approach is a synchronous blocking call, where the scheduler or main thread directly calls the task module's interface, passing in the frame context (such as time increment and input status). After the task module completes its execution, it returns its core calculation result directly as a data object. Another possible approach is message / event-driven, where at the beginning of each frame, a message containing frame parameters is sent to the task module; the task module processes this message asynchronously, publishing the key execution result of this frame to a specific event stream or writing it to a shared frame data buffer for subsequent steps to consume.

[0046] Generating a rendering proxy based on the execution result of the current frame refers to constructing the execution result, which represents the logical state of the current frame, into a data structure with a clear type identifier and instantiation parameters. One possible approach is result mapping and encapsulation. The task module includes a proxy generator that reads the execution result of the current frame, selects the corresponding rendering proxy template based on the type and attributes of the objects in the result, and fills the corresponding fields of the template with the data from the result, thus instantiating a complete rendering proxy object. Another possible approach is for the task module to dynamically create a proxy object of the corresponding type based on the type identifier within the result and call its initialization method to inject the result data.

[0047] In one implementation of this specification, within a game scene, the objective task is to "process the player's input and game state for this frame." The task module is invoked to execute critical task logic: processing player key presses, calculating character movement, performing physical collision detection, and determining if a fireball launched by the player has hit an enemy. Upon completion, the task module obtains the execution result for the current frame, which is a structure containing the hit point coordinates (10, 5, 0), the hit effect identifier "Hit_Spark," and the enemy's hit state "Stunned." Subsequently, based on this execution result, the task module generates a rendering proxy: it creates a proxy of type "Particle System" and sets the position parameter in its "Target Object Data" to (10, 5, 0) and the resource ID to "Hit_Spark." Simultaneously, it may generate another proxy of type "Screen Post-Screen Effects" based on the enemy's "Stunned" state to add a dizzying blur effect.

[0048] In one implementation of this specification, in a data visualization dashboard application, the target task is to "update the sales data chart for this frame." The task module executes the key task logic: querying the latest real-time sales data from the database and calculating a set of data points [(t1, v1), (t2, v2)...], the chart color theme "BlueTheme," and the maximum Y-axis value of 1000 for plotting the line chart. This data set is the execution result for the current frame. Next, the task module generates a rendering proxy based on this result: it creates a proxy of type "2D vector chart" and fills the proxy with the calculated data points, color theme identifier, and maximum Y-axis value as "target object data," so that the rendering module can plot the line chart accordingly.

[0049] By explicitly decomposing the generation of rendering proxies into two sub-steps—obtaining the execution result of the current frame and generating the rendering proxies based on that result—the execution result of the current frame becomes a definite data object that can be observed, recorded, and reused. This facilitates logic debugging, state replay, and performance profiling, improves the maintainability of task execution and the flexibility of the framework, and lays the foundation for possible future expansions.

[0050] During the generation of rendering proxies, there may be issues such as unclear type inference, scattered data acquisition sources, and inconsistent proxy construction methods. This specification provides an optional embodiment to solve the above problems, specifically including the following steps: Based on the execution result of the current frame, determine the type of the target object to be rendered; Obtain the target object data required for rendering the target object; A rendering proxy is constructed based on the type and data of the target object.

[0051] Based on the execution result of the current frame, the type of the target object to be rendered is determined. This is done by parsing the visual intent or data features contained in the execution result and mapping them to a predefined set of object types with corresponding rendering capabilities. One possible approach is rule-based matching mapping, where identifiers representing the expected visual effect (such as "effect type" or "UI element category") are predefined or included in the execution result of the current frame. These identifiers are then converted into corresponding rendering object type identifiers according to a predefined mapping rule table. Another possible approach is data-driven derivation, which analyzes the data structure or key fields of the execution result of the current frame and derives the most matching target object type based on data characteristics (e.g., the presence of "vertex data" suggests a mesh model, while the presence of "particle parameters" suggests a particle system).

[0052] Obtaining the target object data required for rendering refers to collecting and integrating the parameters and associated data of the target object provided by the current frame execution result into a data set that can be processed by the rendering module. One possible approach is to extract it directly from the execution result, which already contains complete or partial data required for rendering (such as coordinates, resource IDs, and state parameters). This data can be read directly and structured. Another possible approach is to rely on resource system queries. Based on resource identifiers (such as "model ID" and "texture path") in the execution result, an asynchronous or synchronous query is initiated to the resource management system to obtain the actual geometric data, texture data, etc., required for rendering, and then merged with other parameters (such as transformation matrices) in the execution result to form the target object data.

[0053] Based on the type and data of the target object, a rendering proxy is constructed. One possible approach is prototype cloning and configuration, which maintains a prototype rendering proxy instance for each type of target object. During construction, the prototype instance of that type is cloned, and then the various attribute fields of the clone are configured using the target object data to form the final rendering proxy.

[0054] In one implementation of this specification, in a game scene, the target task is "handling player attacks in this frame". After the task module executes the critical task logic, it obtains the execution result of the current frame, which includes a list of attack events. One record in the list indicates: "Attack hit, type: fire explosion, position: (x:15, y:0, z:22), intensity: high". First, based on this execution result, the type of the target object to be rendered is determined: according to the "type: fire explosion" field in the record, the preset mapping table is queried to determine that the type of the corresponding target object is "advanced particle system (supports physical interaction)". Next, the target object data required for rendering is obtained: the position (15,0,22) and intensity "high" are directly extracted from the execution result; at the same time, according to the intensity "high", the corresponding particle asset package ID "VFX_Fire_Explosion_High" is obtained; in addition, the normal direction of the explosion point needs to be obtained from the physics system to determine the particle ejection direction. All this information constitutes the complete target object data. Finally, a rendering proxy is built based on type and data: the proxy factory of the "Advanced Particle System" is called, and data such as position, asset ID, and normal direction are passed in to generate a rendering proxy with a clearly defined type that contains all this information.

[0055] In one implementation of this specification, in the real-time preview mode of the 3D modeling software, the target task is "responding to user editing operations in this frame." After the task module (such as the editing logic core) executes the key task logic (such as handling a vertex drag operation), it obtains the execution result of the current frame, indicating: "The vertex set V[0, 3, 5] of mesh 'Cube_01' has been updated, and the new coordinate data is xxx." First, the type of the target object to be rendered is determined: based on the object identifier "mesh 'Cube_01'", the type of its target object is determined to be "editable mesh". Next, the target object data required for rendering is obtained: the updated vertex coordinate data is extracted from the execution result; at the same time, the material information, topology (from the mesh data management module), and world transformation matrix (from the scene graph module) of the mesh need to be obtained to jointly form the target object data. Finally, a rendering proxy is constructed: using the prototype proxy of the "editable mesh" type, a copy is cloned, and the clone is configured with new vertex data, material references, and transformation matrix to form a rendering proxy reflecting the latest editing state, which is used to drive view updates.

[0056] By explicitly breaking down the generation of rendering proxies into three sub-steps—determining the type, acquiring data, and building the proxy—a standardized and manageable implementation path is provided for the process. This makes the generation process of rendering proxies transparent, controllable, and easy to debug, allowing different types of rendering objects to adopt differentiated data acquisition strategies.

[0057] In complex scenarios, blindly submitting the complete data of all objects to the rendering process can lead to performance waste. For example, many objects may be completely invisible because they are off-screen or occluded, but their complete initial data (especially large meshes and high-resolution textures) will still be processed, resulting in low rendering efficiency.

[0058] An optional embodiment of this specification provides a method to solve the above problems, specifically including the following steps; Retrieve the initial object data of the target object; Update the location association information based on the execution result of the current frame; Based on the updated location association information and initial object data, the target object is clipped to obtain the target object data required for rendering the target object.

[0059] Initial object data refers to a relatively static or fundamental set of rendering parameters associated with the target object. It typically does not change frequently with the logical state of each frame and constitutes the basic material for object rendering. For example, for a 3D model, its initial object data may include the model's vertex buffer data, index buffer data, basic texture maps, and material properties (such as background color and roughness). For example, for a UI button, its initial object data may include the button's background texture resource, the string content of the default displayed text, and font resource references.

[0060] Positional association information refers to a set of data describing the position, orientation, and extent of a target object within a specific reference frame (such as world space or screen space), as well as the dynamic spatial relationships such as the state of related observers (such as cameras). For example, in a 3D scene, positional association information may include the target object's model transformation matrix (which determines its position, rotation, and scaling in the world), bounding box data, and the current camera's view matrix and projection matrix. For example, in a 2D UI scene, positional association information may include the coordinates and size of controls on the screen or canvas, as well as the extent of the current viewport.

[0061] In this context, clipping specifically refers to a filtering and optimization process based on spatial positional relationships. Its function is to judge and selectively process initial object data based on updated positional association information (especially the observer's view frustum or visible area) to eliminate objects or parts of their data that are completely outside the visible area and therefore do not need to be rendered in this frame. The result is a streamlined set of data containing only the parts that actually need to be rendered—the target object data required for rendering the target object. For example, clipping could be determined by calculating that the bounding box of a 3D model is completely outside the camera's view frustum, thus deciding to completely skip processing all initial object data of that model in this frame. For example, clipping could also be applied to a long list UI, retaining only the text and texture data corresponding to the list items located within the visible area of ​​the screen.

[0062] One possible way to obtain the initial object data of the target object is to send a query request to the resource management system, using the target object's unique resource identifier (such as model ID, texture path) to retrieve its corresponding geometric data, texture data, etc. Another possible way is to directly retrieve the preloaded data block corresponding to the target object from the object cache pool already loaded into memory.

[0063] Based on the execution result of the current frame, the position association information is updated. One possible approach is to extract the new spatial state of the target object (such as new coordinates and rotation angle) from the execution result of the current frame, and combine it with the hierarchical transformation relationship queried from the scene graph system to calculate the final world transformation matrix and other relevant position information of the object in this frame. Another possible approach is to directly use the final world spatial position and bounding box information after logical calculation in the execution result of the current frame to update the position association information.

[0064] Based on updated location association information and initial object data, the target object is clipped to obtain the target object data required for rendering. One possible approach is view frustum clipping, which uses the updated camera view frustum plane equation to perform an intersection test on the bounding box of the target object (obtainable from the location association information). If the object is completely outside the bounding box, it is determined that the object is completely invisible, generating an empty or "clipped" target object data. If the object intersects or is inside the bounding box, the complete initial object data is retained and merged with the location information to form the final target object data. Another possible approach is hierarchical detail clipping and data selection. For complex objects (such as terrain with LOD (Level of Detail) levels), model data with appropriate LOD levels is selected from the initial object data based on the distance from the object to the camera, discarding other LOD data. The selected data is then merged with the location information to form the final target object data.

[0065] In one implementation of this specification, the target task is to "render dynamic NPCs (non-player characters) in a game scene." First, the initial object data of the target object is obtained: based on the NPC's model ID "NPC_Warrior_01," its skeletal model mesh data, basic diffuse texture, and bone binding information are read from the resource management system. Next, the position association information is updated based on the execution result of the current frame: the execution result of the current frame includes the NPC's logical position (x:100, y:0, z:50) and orientation in this frame. Combined with the scene origin, its model matrix is ​​calculated, and based on the original bounding box of its model mesh, its axis-aligned bounding box (AABB) in the world space of this frame is calculated. Then, clipping is performed: the NPC's AABB is intersected with the current camera's view frustum. The test reveals that the NPC's bounding box is completely outside the camera's view frustum. Therefore, the NPC is determined to be invisible in this frame, and a simplified version of the target object data, marked "culled," is obtained, which does not contain actual mesh and texture data.

[0066] In one implementation of this specification, the objective task is to "render an extremely long scrollable list of friends". First, the initial object data of the target objects is obtained: for each item in the list, its initial object data includes the friend's avatar texture ID, nickname text string, and a preset list item layout template. Next, the position association information is updated based on the execution result of the current frame: the execution result of the current frame includes the user's scrolling operation, which is used to calculate the display range (visible area) of the current list in screen space. Each list item's rectangular range in the list space can be calculated based on its index and item height. Then, clipping is performed: the rectangular range of each list item is intersected with the visible area of ​​the screen. List items completely outside the visible area (e.g., items with indices 0-5 and 30-100) are determined to be invisible. Items intersecting with the visible area (indices 6-29) are determined to be visible. Finally, only the target object data of those visible list items (indices 6-29) is obtained, which includes the avatar texture ID, nickname text, and their precise position on the screen.

[0067] By introducing a pruning step based on location association information, the amount of data transferred from the task module to the rendering module is reduced, the processing burden of the rendering module is lowered, and unnecessary rendering command submissions and GPU workload are avoided, thereby improving overall rendering efficiency and performance.

[0068] In existing technologies, the internal processing logic of the rendering module is fixed, making it difficult to flexibly adapt to different image quality settings, performance requirements, or artistic styles, resulting in monotonous rendering effects or high adaptation costs.

[0069] An optional embodiment of this specification provides a method to solve the above problems, specifically including the following steps: The rendering module is invoked to distribute object data to the rendering components corresponding to the type. Get rendering configuration information; Based on rendering configuration information and rendering components, rendering logic is constructed, and the rendering logic is executed to generate target rendering instructions.

[0070] A rendering component is a functional subunit within the rendering module that is specifically responsible for handling one or a class of specific target objects, encapsulating dedicated rendering algorithms and resource management logic. Each rendering component is highly optimized for the type of object it is responsible for. For example, a rendering component can be a mesh renderer specifically for drawing "static mesh models," encapsulating logic such as vertex buffer binding and indexed drawing calls. For example, a rendering component can also be a particle renderer specifically for handling "particle systems," responsible for managing particle buffers, updating particle states, and performing instantiation drawing.

[0071] Render configuration information refers to a set of configurable parameters and status settings that affect the final quality, effect, and performance of the rendered output. These configurations are typically related to current hardware capabilities, user settings, or the global state of the scene, rather than to a single rendering agent. For example, rendering configuration information may include global shadow quality levels (such as "Off", "Low", "High"), anti-aliasing modes (such as "MSAAx4", "FXAA"), texture filtering settings (such as "Anisotropic Filtering 16x"), or currently active post-processing effects chains (such as "Enable Bloom, Enable Color Correction").

[0072] Distributing object data to the corresponding rendering component via the rendering module means that the rendering module routes the specific data carried in the rendering proxy to the rendering component specifically responsible for processing objects of that type, based on the data type of the target object contained in the rendering proxy. One possible approach is registry lookup and delegation: The rendering module internally maintains a "type-component" registry. When a rendering proxy is received, it queries this table based on the type of its target object, finds the corresponding rendering component instance, and then uses the target object's data as input parameters to call the component's processing interface. Another possible approach is event bus publishing: The rendering module publishes the rendering proxy containing the target object's data as an event to the internal event bus. Each rendering component subscribes to events related to the object types it is interested in. Upon capturing the event, the corresponding rendering component automatically begins processing the data.

[0073] One possible way to obtain rendering configuration information is to read it from a shared configuration store: the rendering module reads the current rendering configuration information from a global, persistent configuration store (such as a configuration file, registry, or in-memory database) during initialization or at the start of each frame. Another possible way is to dynamically obtain it from the rendering context: the rendering module maintains a "rendering context" object, which is updated by higher-level application logic (such as settings menus or scene managers) at the start of each frame or when the state changes. This object contains all the rendering configuration information that should be used in the current frame.

[0074] Based on rendering configuration information and rendering components, rendering logic is constructed and executed to generate target rendering instructions. One possible approach is to pass the rendering configuration information as a parameter to the rendering component, which then selects different internal implementation paths to generate instructions based on the configuration. Another possible approach is to dynamically assemble a rendering pipeline based on the rendering configuration information and schedule the rendering component as a stage of that pipeline for execution.

[0075] In one embodiment of this specification, the rendering module receives a rendering proxy of type "static mesh model". It distributes the model data to the corresponding MeshRenderer component. At the same time, it obtains that the current rendering configuration requires a shadow quality of "high". Based on the "high" shadow quality configuration, the MeshRenderer component selects a shader that supports high-resolution shadows, arranges the rendering pass for generating the shadow map, and finally generates the corresponding drawing instructions.

[0076] In one embodiment of this specification, the rendering module receives a rendering proxy of type "vector text". It distributes the text data to the TextRenderer component. The obtained rendering configuration displays the UI scaled at 150% and with subpixel anti-aliasing enabled. The TextRenderer component then scales and performs subpixel optimization on the text accordingly, generating the final text drawing instructions.

[0077] By decomposing rendering logic into independent, configurable components based on object type and introducing unified rendering configuration information for control, the rendering system can dynamically and flexibly adapt to different rendering needs. This improves the configurability, scalability, and adaptability to different scenarios of the task platform.

[0078] In traditional rendering architectures, when rendering errors occur, debugging information is usually limited to low-level graphics API error codes or general crash addresses, making it difficult to quickly and accurately locate which specific functional module or which input data caused the error, making troubleshooting time-consuming and labor-intensive.

[0079] A rendering error refers to an exception or failure that occurs during the execution of rendering logic, generation, or submission of target rendering instructions by the rendering module due to data, resource, state, or logical problems. For example, a rendering error can be a graphics API call error caused by an invalid resource handle in the target object data (such as pointing to a non-existent texture); for example, a rendering error can also be a runtime crash caused by internal logical defects in the rendering component (such as division by zero errors or buffer overflows).

[0080] Call stack information refers to a record of function or method calls made by the current execution thread, tracing back from the point of error to the point of initiation, when a rendering error occurs. For example, call stack information includes the call sequence of each rendering component along the rendering logic execution path, as well as the identification information of the rendering proxies that triggered these component calls.

[0081] The target rendering component refers to the specific rendering component that, when a rendering error occurs, is determined by analyzing the call stack information and is directly responsible for the error or plays a core role in the error call path. For example, if the error is thrown during the shader binding phase of the MeshRenderer component, then that MeshRenderer is the target rendering component.

[0082] The target rendering proxy refers to the specific rendering proxy that, when a rendering error occurs, is identified by analyzing the call stack information, and is the one that initially triggered the execution of the target rendering component and ultimately caused the error. For example, if the error is ultimately traced back to a rendering proxy containing an invalid texture ID, then that proxy is the target rendering proxy.

[0083] In the event of a rendering error, the target rendering component causing the error and the target rendering proxy that triggered it can be located from the call stack information of the rendering logic. One possible approach is proactive error context capture: at the critical entry point of each rendering component, the unique identifier (such as ID or pointer) of the currently processed rendering proxy is proactively injected into thread-local storage or additional information in the call stack frame. When an error occurs, the error handler can extract the component and proxy information from these pre-defined contexts and report it along with the call stack. Another possible approach is call stack analysis and backtracking: the original call stack information is obtained at the error capture point. A "rendering proxy dispatch record" is maintained, recording which rendering proxy triggered each rendering component call. By parsing the component function at the top of the call stack and performing a backtracking query in conjunction with the dispatch record, the source of the trigger chain (target rendering proxy) and the key components on the path (target rendering component) can be located.

[0084] In one embodiment of this specification, an error occurred in the rendering module while processing a rendering proxy of type "Advanced Particle System," and the graphics API reported "Invalid texture resource handle." The rendering error and call stack information were captured. Analysis of the call stack revealed that the error occurred within the `BindTexture` method of the `ParticleRenderer` component. The call stack showed that this method was invoked by the rendering module's core dispatcher upon receiving the rendering proxy [ID: 0xAA55]. Therefore, the target rendering component was identified as `ParticleRenderer`, and the target rendering proxy was the proxy with ID 0xAA55. Further examination of this proxy revealed that the texture ID "TEX_Missing" contained in its target object data did not exist in the resource system, thus quickly identifying the root cause of the error.

[0085] In one embodiment of this specification, an access violation crash occurred during UI rendering. Call stack information was extracted from the crash dump. The stack information indicated that the crash occurred in the vertex buffer update code of the UIMeshRenderer (front-end mesh renderer) component. By querying the global log of the rendering module (which recorded "Frame X: Start processing rendering proxy [ID: UI_Button_Confirm] -- dispatched to UIMeshRenderer"), the crash point was associated with the specific processing record. This identified the target rendering component as UIMeshRenderer, and the target rendering proxy as the button UI proxy with ID UI_Button_Confirm. Upon inspection, it was found that the proxy's data contained an incorrectly calculated number of vertices, causing a buffer overflow.

[0086] By utilizing the structured call stack information of the rendering module, when a rendering error occurs, it is possible to accurately trace back to the specific target rendering component that caused the error and the target rendering proxy that triggered that component. This allows the development team to directly locate defective component logic or invalid proxy data, improving the maintainability of the rendering system and the efficiency of development and debugging.

[0087] In an optional embodiment of this specification, the task module and the rendering module exchange rendering proxies through an inter-thread communication mechanism.

[0088] Inter-thread communication (IPC) mechanisms refer to specific data exchange and synchronization methods used between software modules running on different execution threads (such as logic threads and rendering threads) to coordinate their work and exchange data. Their function is to allow task modules and rendering modules to execute concurrently in their respective independent threads, while ensuring that rendering proxies are safely and orderly passed from the producer (task module) to the consumer (rendering module). This is crucial for achieving module decoupling and performance improvement. For example, an IPC mechanism can be a thread-safe queue, where the task module pushes generated rendering proxies to the tail of the queue, and the rendering module retrieves proxies from the head of the queue for processing. Alternatively, an IPC mechanism can be a shared memory area protected by a mutex lock, combined with condition variables for notification, used to exchange rendering proxygen data.

[0089] In the implementation of this specification, during game engine runtime, the task module runs on the logic thread, and the rendering module runs on the rendering thread. After the task module completes the critical task logic of "the player casting a fireball," it generates a rendering proxy describing the explosion effect. The task module then passes this proxy to the rendering module through a thread-safe queue (an inter-thread communication mechanism). After retrieving this proxy from the queue, the rendering module executes the rendering logic based on the data within it and generates instructions to drive the GPU to draw, thereby displaying the explosion effect on the screen.

[0090] In the implementation of this specification, in a real-time UI application, the task module running on the logic thread detects data changes and needs to update the list. It generates a UI rendering proxy for each updated list item and places these proxies one by one into a lock-free queue. The rendering module running on the rendering thread retrieves all accumulated proxies from this queue in batches for centralized processing and rendering before each frame's rendering begins.

[0091] Through inter-thread communication mechanisms, thread-level separation and concurrency of logical computation and graphics rendering are achieved, enabling the two modules to work in parallel without blocking each other, thereby improving the overall throughput, response speed and resource utilization of the task platform.

[0092] In one embodiment of this specification, taking the scenario of digital cultural and creative software development as an example, the collaborative execution process of the logic thread, rendering thread, and worker thread pool in this solution is specifically explained. Assume that an event occurs in the game: player character "A" moves to a new location (coordinates (10, 0, 5)) and releases the "Exploding Fireball" skill on the target. Figure 2 This application provides a flowchart of a task execution method for digital cultural and creative software development, which includes the following steps: Step 202: Execution of logical threads and generation of intents. The logic thread (as a task module) executes critical task logic within this frame, handling player actions: calculating the movement path and collision of character "A," determining its final position as coordinates (10, 0, 5); simultaneously processing skill logic, determining that the "explosive fireball" hits the target point (12, 0, 7) and triggering the explosion effect and the target's "burning" status. Based on these logical calculations, the logic thread generates rendering proxies representing the high-level rendering intent: including a proxy of type "skeleton animation character" (carrying the character ID, new transformation matrix, and animation to be played), a proxy of type "advanced particle system" (carrying the explosion position, resource ID "VFX_Fire_Explosion," and intensity parameters), and a proxy of type "dynamic post-processing" (carrying the screen area identifier and "Heat_Wave" filter parameters). These proxies are securely passed to the rendering thread through a lock-free circular buffer queue (an inter-thread communication mechanism).

[0093] Step 204: Parallel computation of the worker thread pool. To improve processing efficiency, the logic thread submits parallelizable, computationally intensive tasks to the worker thread pool: the task of calculating the skeleton skinning matrix for character "A" and the task of simulating the initial particle state (such as initial velocity and diffusion angle) for the "exploding fireball" effect are assigned to the worker thread pool. Threads in the worker thread pool concurrently execute these calculations and temporarily store the results (such as the calculated skeleton matrix and initial particle state data) in shared memory for subsequent consumption by the rendering thread. This avoids the rendering thread being blocked while waiting for these calculations, making full use of multi-core resources to improve the overall frame rate.

[0094] Step 206: Execution of rendering logic and generation of commands in the rendering thread. The rendering thread retrieves rendering proxies from the queue and processes them one by one: For character proxies, after waiting for the worker thread pool to return skeletal data, the character rendering component binds the mesh and materials and uploads matrix data, generating the "DrawIndexedInstanced" instruction; for particle effect proxies, based on the particle state calculated by the worker thread pool, the particle rendering component configures the emitter, updates the particle buffer, and generates the "DrawInstanced" instruction; for post-processing proxies, the post-processing component generates full-screen drawing instructions that apply the "Heat_Wave" shader based on the parameters. All generated target rendering instructions are ultimately submitted to the graphics API to drive the GPU for execution, correctly rendering character movement, explosion effects, and heat wave distortion effects on the screen.

[0095] Step 208: Practical application of the error backtracking mechanism. If an error occurs during the rendering process (e.g., the particle rendering component fails to bind due to a missing texture "Fire_Diffuse"), the captured call stack information can pinpoint the exact location: the error point is in the `ParticleRenderer-BindTexture` method (the target rendering component), and the call chain backtracking shows that it was triggered when the rendering thread processed the proxy [ID: VFX_Fire_001] (the target rendering proxy). Combined with log records (the proxy type is "Advanced Particle System", and the resource ID is "VFX_Fire_Explosion"), the development team can directly lock the rendering proxy that caused the error and the invalid resources it references, quickly locating the fault point between the logical intent (generating the "exploding fireball" effect) and the specific rendering instructions, greatly improving debugging efficiency, and thus improving the overall execution efficiency of the digital cultural product production software.

[0096] Corresponding to the above method embodiments, this application also provides apparatus embodiments. Figure 3 This is a schematic diagram of the structure of a task platform provided in one embodiment of this application. Figure 3 As shown, the device includes: Task module 302 is configured to execute the critical task logic of the target task and generate a rendering proxy, wherein the rendering proxy includes the type of the target object and the target object data required to render the target object; Rendering module 304 is configured to execute rendering logic based on the type and data of the target object and generate target rendering instructions, wherein the target rendering instructions are used to drive the rendering module to execute the target rendering task.

[0097] Optionally, the task module 302 is further configured to execute the key task logic of the target task, obtain the execution result of the current frame, and generate a rendering proxy based on the execution result of the current frame.

[0098] Optionally, task module 302 is further configured to determine the type of the target object to be rendered based on the execution result of the current frame; obtain the target object data required for rendering the target object; and construct a rendering proxy based on the type of the target object and the target object data.

[0099] Optionally, task module 302 is further configured to obtain initial object data of the target object; update position association information based on the execution result of the current frame; and clip the target object based on the updated position association information and initial object data to obtain the target object data required for rendering the target object.

[0100] Optionally, the rendering module 304 is further configured to distribute object data to the rendering component corresponding to the type; obtain rendering configuration information; construct rendering logic based on the rendering configuration information and the rendering component; and execute the rendering logic to generate target rendering instructions.

[0101] Optionally, the task platform also includes a location module configured to locate the target rendering component that caused the rendering error and the target rendering proxy that triggered the target rendering component from the call stack information of the rendering logic in the event of a rendering error.

[0102] Optionally, in the task platform, the task module 302 and the rendering module 304 exchange rendering proxies through an inter-thread communication mechanism.

[0103] The optional embodiments of this specification provide a task platform including a task module and a rendering module. The task module executes the key task logic of the target task, ultimately generating a rendering proxy that includes the type of the target object and the target object data required for rendering the target object. This allows the rendering module to independently and completely execute rendering logic based on the target object type and target object data in the rendering proxy, thereby generating target rendering instructions to drive the rendering module to execute the target rendering task. In this way, when a rendering error occurs, the error can be directly identified as to which rendering proxy caused it, enabling rapid error localization and improving the execution efficiency of tasks in digital cultural product creation software and digital cultural creative software.

[0104] The above is an illustrative scheme of a task platform according to this embodiment. It should be noted that the technical solution of this task platform and the technical solution of the task execution method described above belong to the same concept. Details not described in detail in the technical solution of the task platform can be found in the description of the technical solution of the task execution method described above. Furthermore, the components in the task platform embodiment should be understood as functional modules necessary to implement each step of the program flow or each step of the method; these functional modules are not actual functional divisions or separations.

[0105] Figure 4 This is a structural block diagram of a computing device 400 provided in one embodiment of this application. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0106] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include PSTN (Public Switched Telephone Network), LAN (Local Area Network), WAN (Wide Area Network), PAN (Personal Area Network), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., NIC (Network Interface Controller)), such as an IEEE 802.11 WLAN (Wireless Local Area Network) wireless interface, Wi-MAX (Worldwide Interoperability for Microwave Access) interface, Ethernet interface, USB (Universal Serial Bus) interface, cellular network interface, Bluetooth interface, and NFC (Near Field Communication).

[0107] In one embodiment of this application, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0108] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs (Personal Computers). The computing device 400 can also be a mobile or stationary server.

[0109] The processor 420 is used to execute computer-executable instructions for the task execution method.

[0110] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the task execution method described above.

[0111] One embodiment of this application also provides a computer-readable storage medium storing a computer program / instructions which, when executed by a processor, are used for a task execution method.

[0112] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the task execution method described above.

[0113] One embodiment of this application also provides a computer program product, including a computer program / instructions that, when executed by a processor, are used for a task execution method.

[0114] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the task execution method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the task execution method described above.

[0115] Computer programs / instructions include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, ROM (Read-Only Memory), RAM (Random Access Memory), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in computer-readable media can be appropriately added to or removed according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0116] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0117] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0118] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to specific implementations. Clearly, many modifications and variations can be made based on the content of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.

Claims

1. A task execution method, characterized in that, Applied to a task platform, the task platform including a task module and a rendering module, the method includes: The task module is invoked to execute the key task logic of the target task and generate a rendering proxy, wherein the rendering proxy includes the type of the target object and the target object data required to render the target object; The rendering module is invoked to execute rendering logic based on the type and data of the target object, and to generate target rendering instructions, wherein the target rendering instructions are used to drive the rendering module to execute the target rendering task.

2. The method according to claim 1, characterized in that, The key task logic for invoking the task module to execute the target task and generate a rendering proxy includes: The task module is invoked to execute the key task logic of the target task and obtain the execution result of the current frame; A rendering proxy is generated based on the execution result of the current frame.

3. The method according to claim 2, characterized in that, The step of generating a rendering proxy based on the execution result of the current frame includes: Based on the execution result of the current frame, determine the type of the target object to be rendered; Obtain the target object data required for rendering the target object; A rendering proxy is constructed based on the type of the target object and the target object data.

4. The method according to claim 3, characterized in that, The step of obtaining the target object data required for rendering the target object includes: Obtain the initial object data of the target object; Update the location association information based on the execution result of the current frame; Based on the updated location association information and the initial object data, the target object is cropped to obtain the target object data required for rendering the target object.

5. The method according to any one of claims 1-4, characterized in that, The step of invoking the rendering module to execute rendering logic based on the type and data of the target object, and generating target rendering instructions, includes: The rendering module is invoked to distribute the object data to the rendering component corresponding to the type; Get rendering configuration information; Based on the rendering configuration information and the rendering components, rendering logic is constructed, and the rendering logic is executed to generate target rendering instructions.

6. The method according to claim 5, characterized in that, After the step of calling the rendering module to execute rendering logic based on the type and data of the target object and generate target rendering instructions, it further includes: In the event of a rendering error, the target rendering component that caused the rendering error and the target rendering proxy that triggered the target rendering component are located from the call stack information of the rendering logic.

7. The method according to claim 1, characterized in that, The task module and the rendering module exchange the rendering proxy through an inter-thread communication mechanism.

8. A task platform, characterized in that, The task platform includes a task module and a rendering module; The task module is configured to execute the key task logic of the target task and generate a rendering proxy, wherein the rendering proxy includes the type of the target object and the target object data required to render the target object; The rendering module is configured to execute rendering logic based on the type and data of the target object and generate target rendering instructions, wherein the target rendering instructions are used to drive the rendering module to execute the target rendering task.

9. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, wherein when the computer programs / instructions are executed by the processor, they implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program / instructions that, when executed by a processor, implement the method described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images