Multi-application oriented non-integrated single-engine background rendering method and system

Abstract

The application discloses a multi-application-oriented non-integrated single-engine background rendering method and system, relates to the technical field of computer graphics background rendering and multi-application graphics resource scheduling, and is used for solving the problems of session isolation deficiency, pseudo change amplification caused by dynamic changes of display memory and window caliber and rendering competition under the condition of multi-application non-integrated access. A session is established, and output picture specifications, content descriptions and resource lists are submitted. An engine is checked and standardized, stable node identification and a node fingerprint table are generated, and an off-screen frame buffer is created. The engine forms resource quotas according to display memory and identifies caliber jump pseudo changes, and submission is controlled. A rendering cycle is increased according to a change area or a full frame is redrawn, multi-view multiplexing is supported, results are locally synthesized or remotely encoded and output, and interactive closed-loop updating is realized.

Description

Technical Field

[0001] This invention relates to the field of background rendering and multi-application graphics resource scheduling in computer graphics, and more specifically, to a non-integrated single-engine background rendering method and system for multiple applications. Background Technology

[0002] Current multi-application background rendering often employs embedded rendering engines within each application or a multi-process, multi-engine parallel approach, which can easily lead to process size expansion, inconsistent version updates, and increased interface adaptation costs. When multiple sessions share a graphics processor on the same terminal, fluctuations in video memory usage and abrupt changes in window size and pixel density can trigger frequent resolution adjustments, causing layout unification changes to be misinterpreted as content changes. This results in an abnormally large set of changed nodes, failure of incremental redraws, and intensified submission contention. Furthermore, the lack of unified verification and session ownership constraints for resource byte data can easily lead to cross-session resource misuse, incorrect handle binding, and breaches of security boundaries. Remote streaming scenarios are also affected by link throughput jitter, making it difficult to stabilize the encoding rate. Combined with resource rolling updates, this can cause frame rate jitter and screen tearing.

[0003] To address the above problems, this invention proposes a solution. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a non-integrated single-engine background rendering method and system for multiple applications, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] In a preferred embodiment, it includes:

[0007] Step 1: Receive the session establishment request, generate a rendering session, verify and access the initial content description and resource list, create an off-screen frame buffer and return a ready flag;

[0008] Step 2: Record the caliber state vector and calculate the caliber jump intensity. Decompose the normalized content description into a set of caliber-sensitive attributes and a set of caliber-insensitive attributes. Calculate the fingerprints of caliber-sensitive nodes and caliber-insensitive nodes to obtain the pseudo-change ratio. Combine the resource rolling pulse intensity to form a three-source misalignment coupling anomaly index. Determine the submission share, worker thread quota, and pseudo-change suppression rules based on the gating limit and slow recovery to suppress the amplification of caliber changes.

[0009] Step 3: Receive the incremental content description to obtain the set of changed nodes, select the regional incremental redraw path or the full frame redraw path, generate and submit the drawing command according to the submission share;

[0010] Step 4: After synchronizing the fence position, output the frame result, process the interactive event record, update the normalized content description, and recalculate the set of changed nodes for redrawing in the next rendering cycle.

[0011] In a preferred embodiment, in step one, the application submits a session establishment request without integrating the background rendering engine into its own process. It completes the access with the application identifier, output screen specifications, and authentication credentials. After verification and authentication by the background rendering engine, a rendering session is generated and a session identifier and session key are returned. Subsequently, the application submits an initial content description and resource list. The background rendering engine performs structural verification and resource reference verification on the content description, calculates the content verification value of the resource entity byte data and compares it with the resource list for consistency. If the comparison is successful, the resources are loaded and the session ownership is registered.

[0012] In a preferred embodiment, in step one, based on the successful verification, the content description is subjected to deterministic normalization to fix the representation. Then, stable node identifiers are derived from the normalized hierarchical relationship and node attributes, and then written into the session-level baseline fingerprint and a node fingerprint table is established to support the determination of subsequent change node sets. Finally, an off-screen frame buffer bound to the rendering session is created according to the output screen specifications. After the above deterministic normalization process is completed, the stable node identifier is exported, the session-level baseline fingerprint is written, the node fingerprint table is established, and the off-screen frame buffer is successfully created, the rendering session is marked as ready and the ready flag is returned.

[0013] In a preferred embodiment, in step two, the background rendering engine establishes a session rendering context for the rendering session and forcibly limits its access scope to the normalized content description, loaded resource entities, and bound off-screen frame buffers under the name of the rendering session. At the same time, it creates command buffer allocation pools and resource binding tables by partitioning according to session identifiers, registers additional session identifiers for resource objects, and performs session consistency checks before each resource handle resolution and binding and drawing command submission, rejecting cross-session resource use with session identifier consistency as a prerequisite.

[0014] In a preferred embodiment, in step two, after isolation is established, the background rendering engine calculates the basic usage of the off-screen frame buffer based on the normalized representation of the output screen specifications in step one, the preset mapping of pixel format to bytes per pixel, the fixed configuration of the number of off-screen frame buffers, and the available video memory capacity input obtained from the graphics driver interface. This calculation is then added to the actual usage of the loaded texture objects, font objects, and model objects to form the video memory usage ledger for the rendering session. Subsequently, all rendering session ledgers are summarized and compared with the available video memory capacity. If the limit is not exceeded, the ledger is written to the resource quota table and the output screen specifications remain unchanged. If the limit is exceeded, the effective output screen specifications are corrected according to a deterministic resolution scaling factor, and the off-screen frame buffer usage is recalculated accordingly and written back to the resource quota table.

[0015] In a preferred embodiment, in step two, the background rendering engine records the aperture state vector consisting of window width, window height, pixel density, and effective output screen size in each statistical period and calculates the aperture jump intensity. At the same time, the normalized content description is decomposed into a set of aperture-sensitive attributes and a set of aperture-insensitive attributes according to whether it depends on the aperture for unit conversion and layout normalization. The fingerprints of aperture-sensitive nodes and aperture-insensitive nodes are calculated respectively to obtain two sets of change nodes. Furthermore, the pseudo-change ratio is used to characterize the degree to which aperture change is regarded as content change.

[0016] In a preferred embodiment, in step two, the background rendering engine constructs a resource rolling pulse intensity based on the number of changes in version number or content verification value in the incremental resource list, as well as the number of verification inconsistencies or load rejections. On this basis, instead of using the conventional weighting strategy of pixel scale or fixed weight summation, it constructs a three-source misalignment coupling anomaly index with caliber jump intensity, pseudo-change ratio, and resource rolling pulse intensity. It captures the suddenness of misalignment superposition through multiplicative amplification and extreme value take-major, and switches the session to the gating limit or slow recovery range according to the preset threshold and recovery conditions. When the gating limit is enabled, the background rendering engine first calculates the real demand intensity using logarithmic saturation mapping based on the effective output screen specifications, target frame rate limit, and normalized content description statistics. Then, it forms the submittable demand intensity and normalizes it into a submission share using the gating coefficient linked with the coupling anomaly index and pseudo-change ratio. The submission share is used to perform quota control on the command queue submission frequency, the number of submittable command buffers, and the graphics processor time slice.

[0017] When the coupling anomaly is established and the pseudo-change ratio exceeds the threshold, the pseudo-change suppression rule is further enabled. Only commands associated with the set of nodes that are not sensitive to changes in the caliber are allowed to be recorded and submitted. Large-scale requests triggered only by caliber-sensitive changes are marked as delayed processing to prevent caliber jumps from becoming content change competitions from the source. At the same time, the same submission share mechanism is consistently mapped to the central processing unit worker thread quota. In the abnormal state, the quota is reduced to no less than the minimum value, and the released thread quota is used first for content verification value comparison, resource loading registration, and caliber state vector update.

[0018] In a preferred embodiment, in step three, the background rendering engine receives incremental content descriptions with session identifiers according to the rendering cycle and deterministically normalizes them. Based on the differences in node fingerprints, it extracts a set of changed nodes and generates a set of changed regions from their geometric layout. The coverage ratio is used to choose between incremental region redraw and full frame redraw. Command generation and resource binding are strictly limited to the session rendering context and are verified for consistency between the resource binding table and the session. At the same time, the graphics processor submits the submission share obtained in step two for throttling and time budget control. When multiple sessions differ only in viewpoint and have highly consistent geometric references, they are merged into a multi-view group and multi-view output is generated by single-draw reuse and written to their respective off-screen frame buffers.

[0019] In a preferred embodiment, in step four, after the synchronization fence is set, the background rendering engine only retrieves and outputs frames from the session off-screen frame buffer. In local background mode, it submits the frames to the operating system compositor with a shared surface and performs session consistency verification before submission. In remote streaming mode, it performs format conversion and low-latency encoding, and determines the bitrate by combining link feedback before sending with a session identifier. At the same time, it applies the return interaction event record, maps the event coordinates to the valid output screen specification, and uses stable node identifiers or hit judgments to locate nodes. After updating the normalized content description, it recalculates the node fingerprint to generate a set of changed nodes to drive the next cycle of redrawing.

[0020] In a preferred embodiment, it includes: a rendering session access module, a three-source misaligned coupling gating module, a parallel incremental multiplexing rendering module, an image output interactive closed-loop module, and signal connections between the modules.

[0021] The rendering session access module is used to receive session establishment requests, generate rendering sessions, verify and access the initial content description and resource list, create off-screen frame buffers and return a ready flag.

[0022] The three-source misaligned coupling gating module is used to record the caliber state vector and calculate the caliber jump intensity. It decomposes the normalized content description into a set of caliber-sensitive attributes and a set of caliber-insensitive attributes, calculates the fingerprints of caliber-sensitive nodes and caliber-insensitive nodes to obtain the pseudo-change ratio, and forms a three-source misaligned coupling anomaly index by combining the resource rolling pulse intensity. Based on the gating limit and the slow-release recovery, it determines the submission share, worker thread quota and pseudo-change suppression rules to suppress the amplification of caliber changes.

[0023] The parallel incremental reuse rendering module is used to receive the content description increment to obtain the set of changed nodes, select the region incremental redraw path or the full frame redraw path, generate and submit the drawing command according to the submission share;

[0024] The image output interactive closed-loop module is used to output frame results after the synchronous fence is set, process interactive event records, update standardized content descriptions, and recalculate the set of changed nodes for redrawing in the next rendering cycle.

[0025] The technical effects and advantages of this invention regarding a non-integrated single-engine background rendering method and system for multiple applications are as follows:

[0026] This invention solidifies the source and value basis of output screen specifications by using sessions as boundaries, and combines triple verification of structure / reference / checksum with deterministic normalization to make content, resources, and specifications traceable and reproducible. It achieves strong isolation through consistency verification of session rendering context and resource binding to avoid cross-application handle mixing. It constructs a coupling anomaly index based on specification jump intensity, pseudo-change ratio, and resource rolling pulse intensity, and gates the submission share and thread quota to suppress pseudo-change amplification and memory contention caused by timing misalignment. Combined with change region selection and multi-view reuse, it improves rendering throughput and stabilizes local compositing and remote streaming quality more robustly. Attached Figure Description

[0027] Figure 1 This is a timing diagram of the non-integrated single-engine background rendering method for multiple applications according to the present invention.

[0028] Figure 2 This is a schematic diagram of the modules of the non-integrated single-engine background rendering system for multiple applications according to the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Example

[0031] This invention discloses a non-integrated single-engine background rendering method for multiple applications, such as... Figure 1 As shown, it includes:

[0032] Step 1: Establishing a rendering session and integrating content description;

[0033] First, the application initiates an access operation without integrating the background rendering engine into its own process, submitting a session establishment request to the background rendering engine. This session establishment request includes at least the application identifier, output screen specifications, and authentication credentials. In local background mode, the output screen specifications are derived from the window width, window height, pixel density, and pixel format capabilities provided by the operating system's window manager. In remote streaming mode, the output screen specifications also include a recommended resolution and a recommended frame rate limit obtained from the application's side-link capability assessment, and are submitted along with the session establishment request to fix the source and basis of the output screen specifications.

[0034] After receiving the session establishment request, the background rendering engine performs verification on the authentication credentials; if the verification is successful, a rendering session is generated and the session identifier and session key are returned to the application.

[0035] After the rendering session is generated, the application generates and submits an initial content description and resource list. The data source for the content description is limited to the interface structure data, graphic element attribute data, and 3D scene node data generated during application runtime; the data source for the resource list is limited to resource entity data that the application can legally access and provide to the backend rendering engine, including texture byte data, font byte data, geometric model byte data, and material parameter data.

[0036] The application carries a resource identifier, resource type, version number, and content verification value for each resource entity in the resource manifest, and references the resource entity only through the resource identifier in the content description. After receiving the initial content description and resource manifest, the backend rendering engine first performs structural and reference verification on the initial content description: structural verification is used to confirm that the field set, field type, and hierarchical relationship conform to the preset syntax constraints; reference verification is used to confirm that each resource identifier in the content description can be found in the resource manifest with a corresponding item of the same identifier, and that the corresponding item carries the resource type and content verification value.

[0037] If the structure or reference validation fails, the backend rendering engine rejects the access and returns the reason for the validation failure. If the structure and reference validations pass, the backend rendering engine performs a content validation value comparison on the resource entity pointed to by the resource manifest. That is, the backend rendering engine calculates the content validation value of the resource entity's byte data and compares it with the content validation value carried by the corresponding item in the resource manifest. If the comparison is consistent, the resource entity is loaded as a texture object, font object, or model object and its session ownership is registered. If the comparison is inconsistent, loading is rejected and a reason for inconsistency is returned.

[0038] Furthermore, after successful verification, the background rendering engine performs deterministic normalization processing on the initial content description, normalizing differences in field order, default value visibility, and unit expression under the same semantics to a unified representation. This deterministic normalization processing includes at least unit conversion consistency, default value explicitness, field order normalization, and node attribute representation normalization, and the processing result is recorded as a normalized content description.

[0039] Subsequently, the background rendering engine generates a stable node identifier for each node in the normalized content description. The stable node identifier is derived from the node path description, node type field, sibling index, and anchor attribute set, and satisfies the following definition:

[0040] ID(v)=H(P(v)||T(v)||I(v)||A(v));

[0041] Wherein, ID(v) is the stable node identifier of node v; H is the deterministic hash function; P(v) is the node path description, whose data source is the hierarchical relationship in the content description; T(v) is the node type field, whose data source is the node category in the content description; I(v) is the sibling sequence number, whose data source is the node order in the content description; A(v) is the anchor attribute set, whose data source is the content description field itself, and includes at least one or more of semantic identifiers, control identifiers, or resource reference identifiers.

[0042] After generating stable node identifiers, the background rendering engine calculates and writes the session-level baseline fingerprint, and binds and stores it to the rendering session. The baseline fingerprint satisfies the following definition:

[0043] ;

[0044] in, Baseline fingerprint; For the deterministic serialization result of standardized content description; A normalized representation of the resource list, which includes at least the resource identifier and content verification value; To provide a normalized representation of the output image specifications, it must at least include the target resolution, target frame rate limit, and pixel format. The background rendering engine simultaneously constructs a node fingerprint table, calculating a node fingerprint for each node and recording it as a key-value pair stable node identifier. The node fingerprint satisfies the following definition:

[0045] ;

[0046] in, The node fingerprint of node v; Draw a normalized representation of the node's attributes, with the data source being the content description; This is a normalized representation of the set of node resource references, with its data source being the content description. The background rendering engine also records the method for determining the changed node set, enabling it to calculate the changed node set based on any two received content descriptions. The changed node set satisfies the following:

[0047] ;

[0048] in, For the set of changing nodes; and These are the node fingerprints corresponding to node v when the content descriptions are received in two consecutive instances.

[0049] Finally, the background rendering engine creates an off-screen frame buffer bound to the rendering session based on the output screen specifications. The size and pixel format of the off-screen frame buffer are directly taken from the output screen specification field, and the off-screen frame buffer is associated with the rendering session. When the structure verification passes, the reference verification passes, the content verification value matches, the standardized content description is successfully written, the stable node identifier is successfully generated, the baseline fingerprint is successfully written, the node fingerprint table is successfully written, and the off-screen frame buffer is successfully created, the background rendering engine marks the rendering session as ready and returns a ready flag to the application.

[0050] Step 2: Determine rendering context isolation and resource quotas;

[0051] After receiving the ready flag returned in step one, the background rendering engine establishes a session rendering context for the rendering session and restricts the session rendering context to only access the canonicalized content description under the rendering session name, the resource entities loaded in the resource manifest, and the off-screen frame buffer bound to the rendering session. The session rendering context includes at least a graphics application interface device handle, a command queue handle, a command buffer allocation pool, a pipeline state cache, a resource binding table, and a synchronization barrier set.

[0052] The command buffer allocation pool and resource binding table are created in partitions based on session identifiers. When the background rendering engine registers any resource object internally, it attaches a session identifier and writes it to the resource binding table, ensuring that the handle resolution and binding operations of that resource object must be completed through the resource binding table of that session. Before submitting a drawing command, the background rendering engine performs a session consistency check on the target resource object, that is, it checks whether the session identifier registered by the resource object is consistent with the session identifier of the current session rendering context. If the check is inconsistent, the binding and submission are rejected, and the reason for the session inconsistency is returned, thus completing the mandatory constraint of session isolation before the rendering action occurs.

[0053] After the session rendering context is established, the background rendering engine determines the resource quota for the rendering session and writes the resource quota into the resource quota table, which is stored in association with the session identifier. The input data sources for the resource quota are limited as follows: the output screen specification is taken from the normalized representation of the output screen specification in step one; the pixel format and the number of bytes per pixel are taken from the pixel format field in the output screen specification and converted by the background rendering engine according to a preset mapping table; the number of off-screen frame buffers is taken from the fixed configuration items of the background rendering engine; the available video memory capacity of the graphics processor is taken from the query result of the graphics driver interface, and the safety redundancy reserved by the background rendering engine is deducted; the number of available worker threads of the central processing unit is taken from the fixed concurrency configuration of the background rendering engine and the current session occupancy; the number of bytes occupied by any resource entity is taken from the actual byte length of the resource entity when it is loaded and its allocation result in the graphics memory. The background rendering engine calculates the basic occupancy of the off-screen frame buffer for the rendering session based on the resolution and pixel format in the output screen specification, and writes this basic occupancy as a rigid item in the resource quota table. Its calculation satisfies the following definition:

[0054] ;

[0055] in, Indicates the base number of bytes occupied by the off-screen frame buffer; This indicates the number of off-screen frame buffers, taken from the background rendering engine configuration; W and H represent the target width and target height in the output screen specifications, respectively. This represents the number of bytes per pixel corresponding to the pixel format, taken from the pixel format mapping table. For rendering sessions involving depth buffering or multisampling, the background rendering engine calculates the depth buffer usage and sampling usage based on the depth format capability and sampling multiplier in the output image specifications, and then compares them with... Merge and write into the resource quota table.

[0056] In addition to the off-screen frame buffer base usage, the background rendering engine adds up the actual number of bytes occupied by the texture objects, font objects and model objects that have been successfully loaded in the resource list to form the resource entity usage, which together with the off-screen frame buffer base usage constitutes the video memory usage ledger for this rendering session.

[0057] Next, the background rendering engine uses the available video memory capacity obtained from the graphics driver interface as the upper limit to summarize the video memory usage ledger of all current rendering sessions. If the summarized result does not exceed the available video memory capacity, the current ledger value of each rendering session is written into the resource quota table, allowing the output screen specifications to remain unchanged. If the summarized result exceeds the available video memory capacity, the background rendering engine performs deterministic load reduction on the excess portion and reflects the result in the effective output screen specification field of the resource quota table. The load reduction is calculated using the resolution scaling factor as the sole adjustment quantity, and the background rendering engine calculates the allocatable video memory quota for each rendering session. and occupies space based on the current off-screen framebuffer in this rendering session. Greater than At that time, the resolution scaling factor s is calculated and the effective output screen specifications are corrected accordingly. The calculation satisfies the following:

[0058] ;

[0059] Wherein, the value of 's' is limited to between a preset lower bound and one; the background rendering engine updates the width and height of the effective output image to... and Based on this, the base usage of the off-screen frame buffer is recalculated and written to the updated value. Through this load reduction process, the background rendering engine's satisfaction of video memory constraints is implemented as a computable deterministic action, and this action only uses the output screen specifications, graphics driver query results, and existing configuration items as input;

[0060] It should be noted that, under the condition that multiple applications have completed the establishment of rendering sessions, access to content descriptions and resource lists, writing of standardized content descriptions, generation of stable node identifiers, and writing of node fingerprint tables, and the background rendering engine has established a video memory usage ledger based on the query results of the graphics driver interface and determined the effective output screen specifications through the resolution scaling factor s, when the following three types of dynamic change sources occur in the same time window and are out of sync, a definite change will be treated as a content change problem state.

[0061] Specifically:

[0062] The first type of dynamic change source: short-term fluctuations in available video memory capacity.

[0063] The background rendering engine queries the available video memory capacity through the graphics driver interface. When other graphics processes on the same terminal are using or releasing video memory, the query result will fluctuate between adjacent moments. Once the available video memory capacity fluctuates, the allocatable video memory quota for the rendering session will be affected. As a result, the value of the resolution scaling factor s changes, which in turn causes the effective output screen size to change in adjacent moments; this change is directly reflected in the width and height fields of the effective output screen size.

[0064] The second type of dynamic change source: step changes output by the window manager.

[0065] During operations such as split-screen, window dragging, window snapping, display orientation switching, or pixel density switching, the window width, window height, or pixel density returned by the window manager will change abruptly. The output screen specifications are directly taken from this return value in local background mode, so the output screen specifications will change synchronously with the window manager's return value; this change is also reflected in the width, height, and pixel density fields of the output screen specifications.

[0066] The third type of dynamic change source: the rolling version of the resource list and the pulse submission of content description increments.

[0067] Some applications continuously submit incremental updates to content descriptions and resource lists within a short time window. The version numbers and content verification values ​​of the same resource identifier in the resource list scroll rapidly. The background rendering engine must complete structural verification, reference verification, and content verification value comparison according to predetermined verification actions before it can load the resource entity and register its session ownership. During resource version scrolling, the reference relationship between content descriptions and resource identifiers changes frequently, and the resource binding table and resource usage ledger are updated frequently accordingly.

[0068] When the three types of dynamic change sources mentioned above are superimposed with time-series misalignment, the normalization process includes unit conversion consistency and attribute representation normalization. Since unit conversion and layout normalization are affected by the output screen specifications or effective output screen specifications, the set of change nodes will be abnormally amplified even if the application does not substantially change the drawing intent.

[0069] Specifically, when a first- or second-type change source causes a jump in the output screen specification or effective output screen specification, the normalized drawing attribute representation of the same node... A change in the numerical value at the caliber level will occur, thereby altering the node fingerprint. The node fingerprint and the set of changed nodes are defined as follows:

[0070] ;

[0071] ;

[0072] Here, ID(v) is the stable node identifier, and Ref(v) is the set of node resource references; both can remain unchanged in this problem state. However, as long as Attr(v) changes due to a jump in the output screen specification or the effective output screen specification, it will lead to... Thus The batch contains a large number of nodes, forming an abnormally amplified appearance that looks like a change in content but is actually a change in the scope of the statement.

[0073] Therefore, in this embodiment, after the video memory quota is determined, the background rendering engine determines the graphics processor execution quota and the central processing unit execution quota for the rendering session, and writes the results into the resource quota table. Unlike simply summing based on pixel scale or fixed weights, the background rendering engine first performs caliber-sensitive decomposition and pseudo-change identification on the rendering session in each statistical period, then performs a comprehensive analysis of the degree of misalignment coupling of the three types of dynamic change sources, and finally dynamically determines the submission share, rate limiting status, and worker thread quota based on this.

[0074] Specifically, the background rendering engine records the aperture state vector at the start of each statistical period, denoted as aperture state vector K(t). Its data sources are: the window width, window height, and pixel density in the output screen specifications, and the width and height in the effective output screen specifications. The background rendering engine calculates the aperture jump intensity. Used to characterize the impact of Type I and Type II dynamic change sources on the statistical caliber within the statistical period, satisfying:

[0075] ;

[0076] Where W(t), H(t), and D(t) are the window width, window height, and pixel density, respectively; To effectively output the screen with the specified width and height.

[0077] After the caliber jump intensity calculation is completed, the background rendering engine decomposes the normalized content description of the rendering session into a caliber-sensitive attribute set and a caliber-insensitive attribute set. The caliber-sensitive attribute set is denoted as... Its data source is the layout and geometry fields obtained during the normalization process by standardizing the unit conversion of window width, window height, pixel density, or effective output screen specifications; the set of aperture-insensitive attributes is denoted as The data sources are semantic fields, drawing switch fields, and non-layout attribute fields in the standardized content description that do not rely on the aforementioned caliber state vector.

[0078] During deterministic normalization, the background rendering engine records whether each field reads any component of the caliber state vector K(t) during unit conversion consistency, layout normalization, or geometry normalization. For fields that read any component of the caliber state vector K(t) during normalization, the background rendering engine includes that field in the caliber-sensitive attribute set. For fields where no component of the aperture state vector K(t) has been read, the background rendering engine will classify the field into the aperture-insensitive attribute set. The above classification results are recorded along with the normalized content description, ensuring that the same input content description yields a unique result under the same caliber state vector K(t). and .

[0079] For each node v, the background rendering engine calculates two types of node fingerprints based solely on the stable node identifier ID(v), the caliber-sensitive attribute set, and the caliber-insensitive attribute set: one is the caliber-insensitive node fingerprint. The second is the fingerprint of the aperture-sensitive node. Here, Ref(v,t) is a set of node resource references, sourced from the resource reference field in the standardized content description. The background rendering engine uses this to obtain the sets of nodes whose scope is insensitive to changes. With the set of nodes sensitive to changes in caliber And define pseudo-change ratio Used to describe the degree to which changes in aperture are treated as changes in content:

[0080] ;

[0081] in, This represents the cardinality of the set. The input to this pseudo-change ratio comes entirely from the stable node identifier, the decomposition results of the normalized content description field, and the resource reference set, without introducing any external inferences.

[0082] Meanwhile, the background rendering engine establishes resource scrolling pulse intensity for the third type of dynamic change source. The aforementioned The data sources are: the number of times the version number or content verification value of the same resource identifier changes in the incremental resource list submitted by the application, and the number of verification inconsistencies or load rejections generated by the background rendering engine when performing content verification value comparison on resource entities within the statistical period. The background rendering engine normalizes the above counts according to the total number of resource identifiers in the resource list to obtain the resource scroll pulse intensity. And write it to the session state record field of the resource quota table.

[0083] In obtaining , and Subsequently, the background rendering engine constructs a three-source misalignment coupling anomaly index E(t) to avoid using simple weighted summation as the sole decision-making criterion; the coupling anomaly index uses multiplicative amplification and extreme value dominance to characterize the suddenness of misalignment superposition, satisfying:

[0084] ;

[0085] Where any one of these values ​​is zero, it indicates that the corresponding dynamic change source did not participate in the coupling amplification of that statistical period. The background rendering engine enters different control intervals for the rendering session based on E(t) and a preset threshold: when E(t) is greater than or equal to the coupling trigger threshold, the background rendering engine marks the rendering session as being in a coupling abnormal state and enables gating limits; when E(t) is lower than the recovery threshold and the condition is met for at least a preset number of consecutive periods, the background rendering engine removes the coupling abnormal state and performs a gradual recovery. The coupling trigger threshold, recovery threshold, and number of consecutive periods are all taken from fixed configuration items of the background rendering engine and stored in association with the session identifier.

[0086] When gating limits are enabled, the background rendering engine does not directly use a linear weighted sum of pixel size, node number, and reference number as the session weight. Instead, it first calculates the actual demand intensity D(t) of the session, and then multiplies it by the gating coefficient G(t) to form the submittable demand intensity. The input data for the actual demand intensity D(t) comes from the effective output screen specifications, the target frame rate limit, and statistics describing the normalized content. The statistics use a burst-sensitive but saturable nonlinear mapping to suppress impulse amplification, satisfying:

[0087] ;

[0088] in, The target frame rate is the upper limit, and the data source is the output screen specification; The number of drawable nodes is determined by statistical results from the node type and drawing attribute fields in the standardized content description. The data represents the number of resource references, sourced from statistical results of resource reference sets with standardized content descriptions. It is a natural logarithmic function. The gating coefficient G(t) is determined by the coupling anomaly exponent and the pseudo-change ratio. The background rendering engine adopts interval gating and superimposed with a slow recovery constraint: when the coupling anomaly state is established, G(t) takes a suppression value no greater than one and decreases monotonically with E(t); when the recovery condition is established, G(t) is adjusted up periodically according to the preset recovery step size but does not exceed one, thereby avoiding immediate recovery to the full submission state before the caliber jump has subsided and triggering the coupling anomaly again.

[0089] The background rendering engine employs a deterministic piecewise update rule for the gating coefficient G(t): when the rendering session is in a coupled abnormal state, the background rendering engine updates the gating coefficient according to the preset suppression coefficient β and the preset lower bound Gmin, satisfying the following:

[0090] ;

[0091] When the rendering session is not in a coupled abnormal state and the recovery conditions are met, the background rendering engine performs a slow recovery on the gating coefficient according to the preset recovery step size δ, satisfying:

[0092] ;

[0093] Among them, β, Gmin and δ are all taken from the fixed configuration items of the background rendering engine and stored in association with the session identifier.

[0094] Subsequently, the background rendering engine determines the commit share based on the normalized result of the commit demand intensity and writes it to the commit share field of the resource quota table. For any rendering session i, its commit share... satisfy:

[0095] ;

[0096] The background rendering engine presses when the graphics command is submitted. Limit the command queue submission frequency, the number of command buffers that can be submitted per statistical period, and the available graphics processor time slices; when the rendering session is in a coupled abnormal state and spurious changes occur. When the value exceeds a preset threshold, the background rendering engine enables a pseudo-change suppression rule for that session, meaning that only submissions of nodes with changes insensitive to the statistical criteria are allowed within the current statistical period. The associated command recording and submission requests will be linked to the set of nodes sensitive to caliber changes. And does not belong to The request is marked as a delayed processing request and written to the session state record to avoid large-scale fingerprint changes triggered by changes in the definition being equated as content changes at the commit level and amplified into commit competition.

[0097] Simultaneously, the background rendering engine performs gating allocation of CPU worker thread quotas in accordance with the submitted share, and writes it to the worker thread quota field of the resource quota table: the background rendering engine uses Based on the basic allocation ratio, the total number of available worker threads is proportionally allocated as integers and bound to the session identifier. When a rendering session is in a coupled abnormal state, the background rendering engine reduces the worker thread quota of that session to a level no lower than the preset minimum value, and uses the reduced thread quota to handle necessary calculations related to content verification comparison, resource loading registration, and caliber state vector updates, in order to ensure the intensity of resource scrolling pulses. During high-frequency phases, thread congestion will prevent the verification and registration processes from being amplified into longer time windows, thus preventing anomalies.

[0098] Finally, the background rendering engine writes the session rendering context, resource quota table and rendering session state record in a consistent manner, and performs readiness checks on the off-screen frame buffer, resource object handle, command buffer pool and synchronization fence set. When the session isolation verification rule is successfully written, the video memory quota is successfully written, the committed share is successfully written, the worker thread quota is successfully written and the readiness check passes, the background rendering engine marks the rendering session as executable.

[0099] Step 3: Parallel incremental rendering and multi-view reuse generation;

[0100] When a rendering session is in an executable state, the background rendering engine triggers a rendering cycle according to the target frame rate limit of each rendering session. Within each rendering cycle, it performs content update acceptance, change extraction, drawing command generation, graphics processor submission, and off-screen frame buffer writing for the ready rendering sessions, thereby obtaining the rendering frame result corresponding to that rendering session. Specifically, when an application submits a content update to the background rendering engine, the submission payload is still bounded by the content description and resource list increment, and both carry a session identifier and pass the session key integrity verification. After receiving the update, the background rendering engine performs deterministic normalization processing on the incremental content description, consistent with step one, and recalculates the node fingerprint for the normalized nodes. Then, it determines the set of changed nodes based on the inconsistency between two adjacent node fingerprints. The set of changed nodes satisfies the following condition:

[0101] ;

[0102] in, This represents the set of nodes that have changed during the current rendering cycle. and These represent the node fingerprints corresponding to node v in two consecutive received content descriptions; node fingerprints The input data sources are stable node identifiers, normalized representations of node drawing attributes, and normalized representations of node resource reference sets.

[0103] After obtaining the set of changed nodes, the background rendering engine reads the geometric layout or spatial bounding information of each changed node from the normalized content description based on the set of changed nodes, and calculates the set of changed regions for the current rendering cycle accordingly. The set of changed regions consists of multiple rectangular or bounding box regions, and its data source is the layout or transformation and size fields in the content description. The background rendering engine merges the set of changed regions to obtain the effective changed regions for rendering in the current cycle, and uses the coverage ratio of the effective changed regions as the rendering path selection criterion. The coverage ratio satisfies the following conditions:

[0104] ;

[0105] Where r is the effective change area coverage ratio; The area of ​​the effective change region; and The width and height are the valid output screen specifications for this rendering session, and the data source is the valid output screen specification field written in step two.

[0106] Next, the background rendering engine will compare the coverage ratio r with the preset threshold. Comparison, when r≤ When r > ηr, a region-based incremental redraw path is used; when r > ηr, a full-frame redraw path is used. The threshold... Fixed configuration items are taken from the background rendering engine and associated with the session identifier to avoid introducing sourceless thresholds during the rendering process.

[0107] When using a region-based incremental redraw path, the background rendering engine processes the changed node set. The corresponding nodes execute drawing commands to generate, while the existing cached content of unchanged nodes is maintained without recalculation. In specific implementation, the background rendering engine uses the off-screen frame buffer results generated and written in the previous rendering cycle as the base image, and generates new drawing commands only in the effective change area within the current rendering cycle, overwriting the drawing output of the changed nodes into the corresponding area of ​​the off-screen frame buffer; the generation of drawing commands for changed nodes is performed with the session rendering context as the boundary, using the session's command buffer allocation pool to allocate command buffers and record drawing commands, including rendering state settings, resource binding, drawing calls, and synchronous fence writing.

[0108] In this process, when recording each drawing call, the background rendering engine writes the stable node identifier of the target node that triggered the drawing call as a command attribution marker into the metadata area or parallel record table of the command buffer, so that any command buffer fragment can be mapped to a unique stable node identifier. When the pseudo-change suppression rule is enabled in step two, the background rendering engine filters command buffer fragments based on the command attribution marker, allowing only stable node identifiers corresponding to the attribution marker to belong to the set of nodes with insensitive caliber changes. The command fragment is entered into the submission queue, and the remaining command fragments are marked as deferred processing requests and written into the session state record.

[0109] During resource binding, the background rendering engine reads the handles of texture objects, font objects, model objects, or material parameter objects from the resource binding table of the session and completes the binding. Simultaneously, it performs session consistency checks on the bound resource objects. If the checks are inconsistent, the binding and drawing call are not recorded, and the reason for the session inconsistency is returned. For cases where the same change node is updated multiple times within a single cycle, the background rendering engine merges the updates using the stable node identifier as the key, and generates the final drawing command based on the normalized attributes and resource references of the last update, avoiding the repeated generation of multiple invalid drawing calls for the same node within the same cycle.

[0110] When a full-frame redraw path is used, the background rendering engine reconstructs the entire frame's drawing commands according to the drawing order constraints of the nodes in the normalized content description. In practice, the background rendering engine extracts the set of drawable nodes from the normalized content description and determines the drawing order according to the node hierarchy and the Z-order field.

[0111] Then, a complete command buffer is generated in the session rendering context, containing the rendering state switching, resource binding and drawing calls required for the entire frame, and the drawing output is written to the off-screen frame buffer bound to the session.

[0112] During the full-frame redraw process, the background rendering engine still uses the resource objects that have been verified and successfully loaded in step one as the sole source for the use of resource entities, and still completes the resource handle parsing and binding operations through the resource binding table to avoid the situation where unregistered resources are directly bound.

[0113] In any rendering path, the background rendering engine implements inter-session parallel rendering as a sequence of actions involving parallel command generation and quota-based execution. Specifically, the background rendering engine generates command buffers in parallel for multiple rendering sessions on the central processing unit (CPU) side. The command buffer generation task is scheduled and executed within the worker thread quota determined in step two. After command buffer generation is complete, the background rendering engine throttles the GPU submission according to the submission quota of each rendering session, and calculates the GPU time budget allowed for that session within the current rendering cycle based on the submission quota. The time budget satisfies the following conditions:

[0114] ;

[0115] in, The graphics processor time budget allowed for rendering session i during this rendering cycle; This is the commit share for this rendering session, and the data source is the commit share field written in step two; This is the time budget available for graphics processor execution within this rendering cycle, derived from the fixed cycle length of the background rendering engine and the graphics processor's busy / idle measurement results. The background rendering engine determines the time available for execution within this cycle for a given rendering session when it detects that the cumulative commit execution time has reached a certain threshold. When the session stops submitting new commands for the current period, the unsubmitted command buffer is kept in the session's command queue. When there is still time budget in the current period and there are other rendering sessions that have not reached their time budget, the background rendering engine continues to submit command buffers for other rendering sessions, so that the allocation of the graphics processor time budget is completely driven by the submission share and measurement results.

[0116] When multiple rendering sessions need to draw the same geometry set within the same rendering cycle but differ only in view parameters, the background rendering engine performs multi-view reuse generation for these sessions. Specifically, the background rendering engine calculates the consistency ratio of the geometry reference sets for each pair of candidate rendering sessions. The consistency ratio satisfies the following condition:

[0117] ;

[0118] in, The ratio of geometric consistency between rendering session i and rendering session j; and These are geometric reference sets extracted from the normalized content descriptions of the two sessions, with their data source being the model or mesh class references and their instantiation transformation fields in the node resource reference set. Not less than the preset threshold When the pixel format and rendering state set of two sessions satisfy the same pipeline constraint, the background rendering engine merges the two sessions into the same multi-view group and outputs the multi-view rendering results simultaneously in a single draw call on the graphics processor side. The number of views output by the multi-view is taken from the number of rendering sessions within the multi-view group, and the data sources for the view matrix and projection matrix are the camera node transformation field or view parameter field in the content description of each session. When performing multi-view drawing, the background rendering engine writes the multi-view output to the off-screen frame buffer bound to each session or writes it to multiple off-screen frame buffers and then copies it layer by layer to the off-screen frame buffers of each session. After the writing is completed, the synchronization fence of each session is set, thus completing the generation of frame results within this rendering cycle.

[0119] Step 4: Image synthesis output and interactive closed-loop update;

[0120] After completing the off-screen frame buffer write and obtaining the corresponding synchronization fence setting result in each rendering cycle, the background rendering engine extracts the outputtable frame result from the off-screen frame buffer bound to the rendering session, and outputs the frame result to the application interface host according to the output method determined when the rendering session is established. The data source of the frame result is limited to the content written to the off-screen frame buffer under the rendering session name and its corresponding timestamp and synchronization fence state, and does not introduce application-generated bitmaps or third-party stitched bitmaps.

[0121] When the output mode is local background mode, the background rendering engine submits the frame results to the operating system compositor for display compositing using a shared image surface. Specifically, the background rendering engine creates a shared surface handle that can be recognized by the operating system compositor for the off-screen frame buffer according to the output screen specifications of the rendering session, and binds and registers the shared surface handle with the session identifier of the rendering session; the application requests a display window from the operating system window manager on the local interface carrier and obtains a window identifier, the data source of which is the creation return value of the window manager.

[0122] After obtaining the window identifier, the background rendering engine submits the shared surface handle to the compositing layer corresponding to that window. After the synchronization fence is set, it notifies the operating system compositor to execute the compositing submission, enabling the operating system compositor to composite the frame result of that rendering session as a separate layer into the final display frame using hardware acceleration. To avoid cross-session output mixing, the background rendering engine verifies that the session identifier registered to the shared surface handle matches the session identifier bound to the target window identifier before submitting the shared surface handle. If they do not match, the submission is rejected and the reason for the session inconsistency is returned.

[0123] When the output mode is remote streaming, the background rendering engine performs pixel format conversion and encoding compression on the frame results in the off-screen frame buffer, and then sends them to the application through a secure network channel, where the application decodes and displays them. Specifically, the background rendering engine converts the pixel format of the off-screen frame buffer to the specified YUV format according to the encoder input requirements, and sends the converted frames to a low-latency encoder to generate a bitstream. The encoder's input frame size and target bitrate are jointly determined by the effective output screen specifications of the rendering session, the target frame rate limit, and application-side link feedback. The link feedback data comes from the application's periodic measurements of the current network status, including at least the available throughput estimate and jitter estimate, and is sent back to the background rendering engine through the secure channel of the rendering session. Each time the background rendering engine updates the encoding parameters, it uses the available throughput estimate reported by the application as the bitrate limit input, and the pixel size and frame rate as the bitrate requirement input, to calculate the current target bitrate. The target bitrate satisfies the following definition:

[0124] ;

[0125] in, The target bitrate is to be encoded. This is the estimated available throughput reported by the application side; This is a conservative coefficient used to offset overestimation caused by sudden bursts and measurement errors; and The effective output screen specifications width and height for this rendering session are obtained from the effective output screen specifications field written in step two. The output frame rate is set to a value that does not exceed the target frame rate limit; q is the target bit coefficient per pixel per frame, taken from a fixed configuration item of the background rendering engine and associated with the session identifier. The background rendering engine sets encoder parameters and generates bitstream packets accordingly, attaches the session identifier and frame sequence number to the bitstream packets, and then sends them. The application side only decodes bitstream packets matching the session identifier and delivers them to its interface display control; the decoded display size is taken from the window size information of the application interface, and the data source for this window size information is the query result of the application-side window manager.

[0126] While outputting the frame result, the application submits user interaction input to the background rendering engine as interaction event records. The background rendering engine parses, locates, and updates the state of the interaction event records, thereby forming a content update result bound to the rendering session. The data source for the interaction event records is limited to touch events, mouse events, keyboard events, or gesture events output by the operating system input subsystem. The interaction event records must at least include the event type, event occurrence timestamp, event coordinates or key codes, and application window identifier; the event coordinates data source is the window coordinate system coordinates provided by the operating system input subsystem, and the event occurrence timestamp data source is the event timestamp provided by the operating system or the unified timestamp on the application side.

[0127] The application sends interaction event records to the backend rendering engine via the secure channel of the rendering session. Upon receiving the records, the backend rendering engine maps the event coordinates to the valid output screen coordinate system of the rendering session and performs a hit determination within the normalized content description to locate the target node: when the interaction event record contains a stable node identifier, the backend rendering engine directly locates the target node using the stable node identifier; when the interaction event record only contains event coordinates, the backend rendering engine performs a hit determination based on the node's geometric layout field or enclosure information field in the normalized content description to determine the hit target node, and takes the stable node identifier of that target node as the node attribution marker for this interaction. The data source for the layout field or enclosure information field used in the hit determination is the attribute field of the corresponding node in the normalized content description, without using externally inferred data.

[0128] After determining the target node, the background rendering engine updates and writes the node drawing attributes or node transformation fields in the standardized content description according to the event type, and synchronously updates the resource reference set related to the target node.

[0129] Finally, the background rendering engine recalculates the node fingerprints of the nodes that have been updated, and obtains the set of changed nodes accordingly. The set of changed nodes is still defined in step three. Confirmed; the background rendering engine writes the set of changed nodes and the effective changed area caused by this interaction into the rendering session state record, and performs the corresponding incremental redraw or full frame redraw for the rendering session in the next rendering cycle.

[0130] This invention also proposes a non-integrated single-engine background rendering system for multiple applications, such as... Figure 2 As shown, it includes: a rendering session access module, a three-source misaligned coupling gating module, a parallel incremental multiplexing rendering module, an image output interactive closed-loop module, and signal connections between the modules;

[0131] The rendering session access module is used to receive session establishment requests, generate rendering sessions, verify and access the initial content description and resource list, create off-screen frame buffers and return a ready flag.

[0132] The three-source misaligned coupling gating module is used to record the caliber state vector and calculate the caliber jump intensity. It decomposes the normalized content description into a set of caliber-sensitive attributes and a set of caliber-insensitive attributes, calculates the fingerprints of caliber-sensitive nodes and caliber-insensitive nodes to obtain the pseudo-change ratio, and forms a three-source misaligned coupling anomaly index by combining the resource rolling pulse intensity. Based on the gating limit and the slow-release recovery, it determines the submission share, worker thread quota and pseudo-change suppression rules to suppress the amplification of caliber changes.

[0133] The parallel incremental reuse rendering module is used to receive the content description increment to obtain the set of changed nodes, select the region incremental redraw path or the full frame redraw path, generate and submit the drawing command according to the submission share;

[0134] The image output interactive closed-loop module is used to output frame results after the synchronous fence is set, process interactive event records, update standardized content descriptions, and recalculate the set of changed nodes for redrawing in the next rendering cycle.

[0135] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0136] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0137] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0138] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0140] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A non-integrated single-engine background rendering method for multiple applications, characterized in that: include: Step 1: Receive the session establishment request, generate a rendering session, verify and access the initial content description and resource list, create an off-screen frame buffer and return a ready flag; Step 2: Record the caliber state vector and calculate the caliber jump intensity. Decompose the normalized content description into a set of caliber-sensitive attributes and a set of caliber-insensitive attributes. Calculate the fingerprints of caliber-sensitive nodes and caliber-insensitive nodes to obtain the pseudo-change ratio. Combine the resource rolling pulse intensity to form a three-source misalignment coupling anomaly index. Determine the submission share, worker thread quota, and pseudo-change suppression rules based on the gating limit and slow recovery to suppress the amplification of caliber changes. Step 3: Receive the incremental content description to obtain the set of changed nodes, select the regional incremental redraw path or the full frame redraw path, generate and submit the drawing command according to the submission share; Step 4: After synchronizing the fence position, output the frame result, process the interactive event record, update the normalized content description, and recalculate the set of changed nodes for redrawing in the next rendering cycle.

2. The non-integrated single-engine background rendering method for multiple applications according to claim 1, characterized in that: In step one, the application submits a session establishment request without integrating the background rendering engine into its own process. It completes the access with the application identifier, output screen specifications and authentication credentials. After the background rendering engine verifies and authenticates the request, it generates a rendering session and returns the session identifier and session key. The application then submits an initial content description and resource list. The background rendering engine performs structural and resource reference checks on the content description, calculates the content verification value for the resource entity byte data, and compares it with the resource list for consistency. If the comparison is successful, the resources are loaded and the session ownership is registered.

3. The non-integrated single-engine background rendering method for multiple applications as described in claim 2, characterized in that: In step one, based on the successful verification, the content description is subjected to deterministic normalization to fix the representation. Then, stable node identifiers are derived from the normalized hierarchical relationship and node attributes, and then written into the session-level baseline fingerprint and a node fingerprint table is established to support the determination of subsequent change node sets. Finally, an off-screen frame buffer bound to the rendering session is created according to the output screen specifications. After the deterministic normalization process is completed, the stable node identifier is exported, the session-level baseline fingerprint is written, the node fingerprint table is established, and the off-screen frame buffer is successfully created, the rendering session is marked as ready and the ready flag is returned.

4. The non-integrated single-engine background rendering method for multiple applications according to claim 1, characterized in that: In step two, the background rendering engine establishes a session rendering context for the rendering session and forcibly limits its access scope to the normalized content description, loaded resource entities and bound off-screen frame buffers under the name of the rendering session. At the same time, it creates command buffer allocation pool and resource binding table partitioned by session identifier, registers additional session identifiers for resource objects, and performs session consistency verification before each resource handle resolution and binding and drawing command submission, rejecting cross-session resource use with the session identifier consistency as a prerequisite.

5. The non-integrated single-engine background rendering method for multiple applications according to claim 4, characterized in that: In step two, after isolation is established, the background rendering engine calculates the basic usage of the off-screen frame buffer based on the normalized representation of the output screen specifications from step one, the preset mapping of pixel format to bytes per pixel, the fixed configuration of the number of off-screen frame buffers, and the available video memory capacity input obtained from the graphics driver interface. This calculation is then added to the actual usage of the loaded texture objects, font objects, and model objects to form the video memory usage ledger for the rendering session. Subsequently, all rendering session ledgers are summarized and compared with the available video memory capacity. If the limit is not exceeded, the ledger is written to the resource quota table and the output screen specifications remain unchanged. If the limit is exceeded, the effective output screen specifications are corrected according to a deterministic resolution scaling factor, and the off-screen frame buffer usage is recalculated accordingly and written back to the resource quota table.

6. The non-integrated single-engine background rendering method for multiple applications according to claim 1, characterized in that: In step two, the background rendering engine records the aperture state vector, which consists of window width, window height, pixel density, and effective output screen size in each statistical period, and calculates the aperture jump intensity. At the same time, the normalized content description is decomposed into aperture-sensitive attribute set and aperture-insensitive attribute set according to whether it depends on the aperture for unit conversion and layout normalization. The fingerprints of aperture-sensitive nodes and aperture-insensitive nodes are calculated respectively to obtain two types of change node sets. Furthermore, the pseudo-change ratio is used to characterize the degree to which aperture change is regarded as content change.

7. The non-integrated single-engine background rendering method for multiple applications according to claim 6, characterized in that: In step two, the background rendering engine constructs the resource rolling pulse intensity based on the number of changes in the version number or content check value in the incremental resource list and the number of check inconsistencies or load rejections. Based on this, instead of using conventional weighting strategies that rely on pixel scale or fixed weight summation, a three-source misalignment coupling anomaly index is constructed using aperture jump intensity, pseudo-change ratio, and resource rolling pulse intensity. This index captures the suddenness of misalignment superposition through multiplicative amplification and extreme value dominance. Based on preset thresholds and recovery conditions, the session is switched to a gating limit or a gradual recovery range. When the gating limit is enabled, the background rendering engine first calculates the real demand intensity using logarithmic saturation mapping based on the effective output screen specifications, target frame rate limit, and normalized content description statistics. Then, the gating coefficient linked to the coupling anomaly index and pseudo-change ratio forms the submittable demand intensity and normalizes it into a submission share. This submission share is used to implement quota control on the command queue submission frequency, the number of submittable command buffers, and the graphics processor time slice. When the coupling anomaly is established and the pseudo-change ratio exceeds the threshold, the pseudo-change suppression rule is further enabled. Only commands associated with the set of nodes that are not sensitive to changes in the caliber are allowed to be recorded and submitted. Large-scale requests triggered only by caliber-sensitive changes are marked as delayed processing to prevent caliber jumps from becoming content change competitions from the source. At the same time, the same submission share mechanism is consistently mapped to the central processing unit worker thread quota. In the abnormal state, the quota is reduced to no less than the minimum value, and the released thread quota is used first for content verification value comparison, resource loading registration, and caliber state vector update.

8. The non-integrated single-engine background rendering method for multiple applications according to claim 1, characterized in that: In step three, the background rendering engine receives incremental content descriptions with session identifiers according to the rendering cycle and performs deterministic normalization. It extracts the set of changed nodes based on node fingerprint differences and generates a set of changed regions from their geometric layout. The engine then chooses between incremental region redrawing and full-frame redrawing based on coverage ratio. Command generation and resource binding are strictly limited to the session rendering context and are verified for consistency between the resource binding table and the session. Meanwhile, the graphics processor submits the submission share obtained in step two for throttling and time budget control. When multiple sessions differ only in viewpoint and have highly consistent geometric references, they are merged into a multi-view group to generate multi-view outputs using single-draw reuse and written to their respective off-screen frame buffers.

9. The non-integrated single-engine background rendering method for multiple applications according to claim 1, characterized in that: In step four, after the synchronization fence is set, the background rendering engine only retrieves and outputs frames from the session off-screen frame buffer. In local background mode, it submits the frames to the operating system compositor with a shared surface and performs session consistency verification before submission. In remote streaming mode, it performs format conversion and low-latency encoding, and determines the bitrate by combining link feedback before sending with a session identifier. At the same time, it applies the return interaction event record, maps the event coordinates to the valid output screen specification, and uses stable node identifiers or hit judgments to locate nodes. After updating the normalized content description, it recalculates the node fingerprint to generate a set of changed nodes to drive the next cycle of redrawing.

10. A non-integrated single-engine background rendering system for multiple applications, used to implement the non-integrated single-engine background rendering method for multiple applications as described in any one of claims 1-9, characterized in that, include: Rendering session access module, three-source misaligned coupling gating module, parallel incremental multiplexing rendering module, image output interactive closed-loop module, and signal connections between modules; The rendering session access module is used to receive session establishment requests, generate rendering sessions, verify and access the initial content description and resource list, create off-screen frame buffers and return a ready flag. The three-source misaligned coupling gating module is used to record the caliber state vector and calculate the caliber jump intensity. It decomposes the normalized content description into a set of caliber-sensitive attributes and a set of caliber-insensitive attributes, calculates the fingerprints of caliber-sensitive nodes and caliber-insensitive nodes to obtain the pseudo-change ratio, and forms a three-source misaligned coupling anomaly index by combining the resource rolling pulse intensity. Based on the gating limit and the slow-release recovery, it determines the submission share, worker thread quota and pseudo-change suppression rules to suppress the amplification of caliber changes. The parallel incremental reuse rendering module is used to receive the content description increment to obtain the set of changed nodes, select the region incremental redraw path or the full frame redraw path, generate and submit the drawing command according to the submission share; The image output interaction closed-loop module is used to output frame results after the synchronous fence is set, process interaction event records, update and standardize content descriptions, and recalculate the set of changed nodes for redrawing in the next rendering cycle.

Images