Image rendering method, device and system, electronic equipment and readable storage medium

Abstract

The invention provides an image rendering method, device and system, electronic equipment and a readable storage medium, and relates to the technical fields of graphic rendering, asynchronous rendering, state synchronization and the like. The method is applied to a client communicating with an X server, and comprises the following steps: initiating a special event query operation to the X server before rendering operation is performed on each image frame; obtaining a to-be-processed special event which is returned by the X server in response to the received special event query operation and accumulated after the rendering operation is performed on the previous image frame and before the rendering operation is performed on the current image frame; and processing the to-be-processed special event, and rendering the current image frame according to an obtained processing result. The special event query operation is initiated to the X server only before the rendering operation is performed on each image frame, so that the centralization of special event query is realized, the system calling times are remarkably reduced, and the CPU load of the client is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to the fields of graphics rendering, asynchronous rendering, and state synchronization, and particularly to an image rendering method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] In the existing X11 (X Window System Version 11) graphics system architecture (a network-transparent graphical window system primarily used in Unix / Linux systems), the client and the X server (i.e., the server running the X protocol, which defines the communication rules between the client and server under the X11 architecture) use an asynchronous communication mechanism. This means that the client submits a drawing command and returns immediately, while the actual rendering operation is performed by the server in the background. To ensure that the client and server states are synchronized during critical operations (such as window resizing or displaying newly drawn images), and to avoid screen tearing or resource contention, existing technologies typically rely on the `xcb_poll_for_special_event` function for explicit synchronization.

[0003] Specifically, upon receiving an event indicating a window size change, or when preparing to render a frame of data after submission, the client needs to call this function and wait for the X server to return an Idle Notify special event to confirm that all pending graphics commands have been processed. Although this method effectively ensures rendering correctness, it can lead to a large number of calls to xcb_poll_for_special_event in scenarios with frequent window resizing or high frame rate rendering.

[0004] This frequent polling mechanism not only leads to increased CPU utilization and system overhead, but may also introduce unnecessary latency due to blocking and waiting, affecting application responsiveness and overall energy efficiency. Summary of the Invention

[0005] This disclosure provides an image rendering method, apparatus, system, electronic device, computer-readable storage medium, and computer program product.

[0006] In a first aspect, embodiments of this disclosure propose an image rendering method applied to a client communicating with an X server. The method includes: before rendering each image frame, initiating a special event query operation to the X server; obtaining the pending special events returned by the X server in response to the received special event query operation, which are accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame; processing the pending special events; and rendering the current image frame based on the obtained processing result.

[0007] Secondly, embodiments of this disclosure provide an image rendering apparatus for use in a client communicating with an X server. The apparatus includes: a special event query operation initiation unit configured to initiate a special event query operation to the X server before rendering each image frame; a special event acquisition unit configured to acquire the pending special events returned by the X server in response to the received special event query operation, which are accumulated after rendering the previous image frame and before rendering the current image frame; and a special event processing unit configured to process each pending special event and render the current image frame based on the processing result.

[0008] Thirdly, embodiments of this disclosure propose an image rendering system, comprising: a client, configured to initiate a special event query operation to an X server before rendering each image frame; obtain all pending special events returned by the X server in response to the received special event query operation; process each pending special event and render the current image frame according to the obtained processing result; and an X server, configured to return the currently accumulated pending special events to the client according to the received special event query operation.

[0009] Fourthly, embodiments of this disclosure provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the image rendering method described in the first aspect.

[0010] Fifthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to implement the image rendering method as described in the first aspect when executed.

[0011] In a sixth aspect, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the steps of the image rendering method as described in the first aspect.

[0012] To address the technical issues of high CPU utilization, wasted system resources, response latency, and excessive synchronization caused by frequent special event queries from the client in the asynchronous communication mechanism between the client and the X server in the existing X11 graphics system architecture, the image rendering solution provided in this disclosure initiates a special event query operation to the X server only once before rendering each image frame. This allows for the centralized acquisition of all pending special events accumulated from the rendering operation of the previous image frame to the rendering operation of the current image frame, thus significantly reducing the number of system calls and lowering the CPU load on the client. Simultaneously, centralized processing of all acquired pending special events ensures that the current frame rendering is based on the latest window state and image resource state, optimizing the continuity of the rendering process and avoiding the untimely state synchronization problem caused by scattered polling in existing technologies. This significantly improves the client's response speed and real-time performance, enhancing the user experience.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is an exemplary system architecture to which this disclosure can be applied; Figure 2 A flowchart of an image rendering method provided in an embodiment of this disclosure; Figure 3 A flowchart illustrating a method for processing various special events based on event type and processing order, provided in this embodiment of the disclosure; Figure 4 A flowchart illustrating another image rendering method in an application scenario provided by an embodiment of this disclosure; Figure 5 A structural block diagram of an image rendering apparatus provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device suitable for performing an image rendering method, provided as an embodiment of the present disclosure. Detailed Implementation

[0015] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0017] Figure 1 An exemplary system architecture 100 is shown, to which embodiments of the image rendering methods, apparatus, electronic devices, and computer-readable storage media of the present disclosure can be applied.

[0018] like Figure 1 As shown, system architecture 100 is an X11 graphics system architecture, which may include terminal devices 101, 102, and 103, a network 104, and an X server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and the X server 105. Communication between terminal devices 101, 102, and 103 and the X server 105 is based on the X protocol. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0019] Users can use terminal devices 101, 102, and 103 to interact with the X server 105 via network 104 to receive or send messages. For example, users can use terminal devices 101, 102, and 103 to send a command to the X server to adjust the size of the interface window displayed by a certain application. Various applications for communication between the terminal devices 101, 102, and 103 and the X server 105 can be installed. These applications include status synchronization applications, graphics rendering applications, and instant messaging applications.

[0020] Terminal devices 101, 102, and 103, and X server 105 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices, and can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here. When X server 105 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules, or as a single software program or software module; no specific limitation is made here.

[0021] Terminal devices 101, 102, and 103 can provide various services through built-in applications. Taking a graphics rendering application as an example, when running this graphics rendering application, terminal devices 101, 102, and 103 can achieve the following effects: First, before rendering each image frame, a special event query operation is initiated to the X server 105; then, the pending special events returned by the X server after the rendering operation of the previous image frame and before the rendering operation of the current image frame are obtained; finally, each pending special event is processed, and the current image frame is rendered according to the processing result.

[0022] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0023] Please refer to Figure 2 , Figure 2 A flowchart of an image rendering method provided in this disclosure embodiment, wherein process 200 includes the following steps: Step 201: Before rendering each image frame, initiate a special event query operation to the X server; This step is intended for the execution body of the image rendering method (e.g., Figure 1 The terminal devices 101, 102, and 103 shown here initiate a special event query operation to the X server only before rendering each image frame. That is, assuming there are 60 frames per second, each device initiates an xcb_poll_for_special_event query to the X server only before rendering these 60 image frames.

[0024] In traditional solutions, clients frequently call event query functions (such as `xcb_poll_for_special_event`) across multiple dispersed stages, including rendering and resource acquisition, to respond to events promptly. This results in numerous meaningless system calls, meaning that even without new events, the client will repeatedly check, wasting CPU resources. This step limits the query operation to "only once before each image frame is rendered." Essentially, it associates and binds event queries with frame rendering, leveraging the periodicity of frames (such as the 60 / 144 frames per second cycle in games or graphics applications) to retrieve and process all pending special events accumulated on the X server from the completion of the previous frame's rendering to the start of the current frame all at once. The core principle of this design is to synchronize the state on a frame-by-frame basis. The rendering of each image frame must be based on the latest system state (such as window size and image resource availability). A single query before the start of a frame is sufficient to cover all events affecting the current frame, ensuring no omissions (all server-accumulated events are returned) and avoiding redundancy (no need for multiple queries within a frame).

[0025] In practice, this operation is typically embedded in the client's main rendering loop. For example, a game application's main loop runs at a fixed frame rate (e.g., 60Hz), and the first step of each loop is to call the `xcb_poll_for_special_event` function to query the X server for special events. These special events specifically refer to critical events affecting the rendering process, mainly falling into two categories: one is `XCB_PRESENT_CONFIGURE_NOTIFY` (window size change event, also known as window configuration event), indicating that the user has adjusted the window size, requiring the client to update the rendering resolution; the other is `XCB_PRESENT_IDLE_NOTIFY` (image idle event), indicating that the server has finished displaying an image, and that image resource can be reused. After the query is completed, the client processes these events (such as updating the window size and marking idle images) before drawing the current frame (such as rendering a 3D scene or drawing the UI).

[0026] This approach not only reduces the number of calls to a single query method concentrated before each frame to match the frame rate (e.g., 60 times / second for 60 frames / second), thus significantly reducing system call overhead; secondly, it ensures timely state synchronization, processing all accumulated events before each frame to ensure the current frame is rendered with the latest state, avoiding the lag problem of "the window has been resized but the rendering still uses the old size"; finally, by acquiring all image idle events at once, it not only marks available resources in a timely manner but also avoids the repeated creation of image buffers (such as image resources in a Swapchain, where Swapchain can be translated as a set of image buffers used to store the rendering results of each frame), reducing memory allocation overhead.

[0027] Step 202: Obtain the special events to be processed accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame, as returned by the X server in response to the received special event query operation. Building upon step 201, this step aims to obtain, through the aforementioned executing entity, all pending special events accumulated by the X server in response to the received special event query operation, prior to the rendering of the previous image frame and prior to the rendering of the current image frame. In simpler terms, it involves obtaining all newly accumulated pending special events from the time the X server returned all accumulated pending special events for the last received special event query request until the current special event query request is received. This addresses the problem of incomplete event retrieval or duplicate queries in traditional distributed queries by coordinating event accumulation with frame periods.

[0028] Because communication between the client and server in the X11 architecture follows a "request-response" model—that is, after the client submits rendering commands (such as drawing images) to the X server, the X server processes these commands asynchronously in the background. The results of the processing (such as changes in window size or availability of image resources) are stored in the X server's event queue as "events" (for example, a window configuration request initiated by the client to the X server will be processed by the X server to generate a corresponding window configuration event, while a window request initiated by the client to the X server will be generated by the client responding to a window adjustment operation initiated by the user on a window running on the client), waiting for the client to actively query. Therefore, the time period described in this step, "from the rendering operation of the previous image frame to the rendering operation of the current image frame," is precisely the transition phase between the X server processing the "rendering result of the previous frame" and "preparation for rendering the current frame." That is, all rendering-related key events (i.e., "special events") processed by the X server during this period will directly affect the rendering logic of the current frame (such as whether the window size changes or whether there are available images to reuse). Therefore, this step essentially binds the "X server processing result" to the "client rendering frame" to ensure that the rendering of the current frame is based on the "latest system state".

[0029] As can be seen from the two types of special events mentioned above, the common feature of these two types of events is that if they are not handled in time, they will cause rendering errors or performance degradation in the current frame (such as if the window size changes and is not handled, the current frame will still be rendered with the old size, resulting in image stretching; if the image idle event is not handled, the current frame cannot reuse resources and memory needs to be reallocated). However, it should be noted that if the X server receives multiple window configuration requests for the same window from the client within a processing interval (e.g., from the time the previous image frame rendering operation is completed until the time the current image frame rendering operation is completed), the X server will not process and generate a corresponding window configuration event for each window configuration request. This is because the configuration parameters corresponding to the window configuration requests initiated later should override the configuration parameters corresponding to the window configuration requests initiated earlier. That is, the window size corresponding to the latest window configuration request should be the latest, and what the user needs is to present the corresponding window size according to their latest window adjustment operation. Therefore, if the X server receives multiple window configuration requests for the same window after the previous special event query operation and before the next special event query operation, it will usually only process and generate a window configuration event (also called the latest window configuration event) for the window configuration request with the latest timestamp (which can be called the latest window configuration request). Therefore, among all the pending special events returned by the X server in any processing interval, there are either no window configuration events or only one window configuration event (i.e., the latest window configuration event).

[0030] At the practical level, the implementation of the retrieval operation relies on the `xcb_poll_for_special_event` function provided by the XCB (XC Binding, a C library used to communicate with the X11 server) library. The key feature of this function is that it returns all pending "special events" (i.e., the two types of events mentioned above) in the server's event queue at once, rather than returning a single event at a time. For example, in the "rendering main loop" of a game application, calling this function before the start of each frame will return a list of events containing all `XCB_PRESENT_CONFIGURE_NOTIFY` and `XCB_PRESENT_IDLE_NOTIFY` events accumulated by the server since the previous frame. This accumulation is crucial; the X server stores all special events processed between two frames in a queue, only returning them when the client queries them. Therefore, a single call can retrieve all events within this timeframe, eliminating the need for multiple calls.

[0031] For a concrete example: Suppose an application runs at a frame rate of 60Hz (approximately 16.7ms per frame). After frame N is rendered (the Nth frame is submitted to server X for display), the user adjusts the window size. Server X processes this operation and generates an `XCB_PRESENT_CONFIGURE_NOTIFY` event, which is then queued. Simultaneously, the server completes the display of frame N-1, generating an `XCB_PRESENT_IDLE_NOTIFY` event and queuing it. Before frame N+1 begins rendering (approximately 16.7ms later), the client calls the `xcb_poll_for_special_event` function, which retrieves both events at once. The former informs the client that "the window size has changed," while the latter indicates that "an image is now available." After the client processes these two events, frame N+1 is rendered with the new window size, reusing available image resources, ensuring both rendering accuracy and efficiency.

[0032] Step 203: Process each special event to be processed, and render the current image frame based on the processing results.

[0033] Building upon step 202, this step aims to have the aforementioned executing entity process each special event to be processed, and render the current image frame based on the processing results. The goal is to correctly process the event information returned by the X server into a local state update on the client, thereby ensuring the correctness and efficiency of the current frame rendering.

[0034] At the technical level, special events need to be processed because they directly affect two key dimensions of rendering: correctness and efficiency. Regarding correctness, a window size change (XCB_PRESENT_CONFIGURE_NOTIFY) can cause a mismatch between the size of previously created image resources (such as images in a swap chain) and the window. If left unprocessed, rendering the current frame at the old size will result in image stretching, cropping, or display errors. Regarding efficiency, an image idle event (XCB_PRESENT_IDLE_NOTIFY) indicates that the server has released the right to use an image. If left unprocessed, the client cannot reuse the resource and must reallocate memory, leading to increased memory overhead and higher rendering latency. Therefore, processing these special events essentially synchronizes the state changes on the X server to the client, thereby providing the "latest and correct input" for rendering the current frame.

[0035] In practical terms, this step requires executing different logic for the two types of special events, but the core principle remains the same: "extract event information → update local state." One specific implementation could be: determine the event type of the special event to be processed. This event type can include: window configuration type and image idle type, corresponding to the window configuration event (or latest window configuration event) and image idle event, respectively; process the special event according to the processing method corresponding to its event type.

[0036] Because the event queue returned by the X server may contain a mix of different types of special events, each carrying entirely different information and requiring completely different responses, they must first be classified and identified to implement a matching processing strategy based on the event type. This event type is determined by a specific field in the event data structure (usually `response_type`). Specifically, window configuration events (such as the aforementioned window size change event) specifically convey changes in window geometry, with the core information being the new width and height; while image idle events specifically indicate changes in the lifecycle of image resources, with the core information being the pixmap handle identifying a specific image resource. These two types of events are fundamentally different: window configuration events are related to rendering correctness to ensure error-free rendering; image idle events are related to rendering efficiency, requiring performance optimization through updating resource states.

[0037] Specifically, after calling `xcb_poll_for_special_event` and obtaining a list of events, the client immediately starts a loop to check each event in the list. For each event, the client reads its event type field. If the value of this field equals `XCB_PRESENT_CONFIGURE_NOTIFY`, the event is identified as a window configuration event; if it equals `XCB_PRESENT_IDLE_NOTIFY`, it is identified as an image idle event. Once the classification is complete, the associated dedicated handler can be triggered. For example, when handling a window configuration event, the program accesses the members named `width` and `height` in the event structure, updates them to the local window size variable, and sets a "resource rebuild flag" (e.g., `window_resized = true`). This process is identification, not execution. The actual execution (such as rebuilding the swap chain) is usually scheduled in the subsequent unified resource management phase, ensuring the modularity and timing controllability of the processing logic. After processing is complete, the results will exist in the form of local states (such as the need_rebuild_swapchain flag and the image states in image_list). These states will directly guide the rendering process of the current frame. For example, after selecting the required image resources, the client will perform rendering operations on the resources (such as drawing 3D scenes and UI elements) and finally submit the rendering results to the X server for display.

[0038] To address the technical issues of high CPU utilization, wasted system resources, response latency, and excessive synchronization caused by frequent special event queries from the client in the asynchronous communication mechanism between the client and the X server in the existing X11 graphics system architecture, the image rendering solution provided in this disclosure initiates a special event query operation to the X server only once before rendering each image frame. This allows for the centralized acquisition of all pending special events accumulated from the rendering operation of the previous image frame to the rendering operation of the current image frame, thus significantly reducing the number of system calls and lowering the CPU load on the client. Simultaneously, centralized processing of all acquired pending special events ensures that the current frame rendering is based on the latest window state and image resource state, optimizing the continuity of the rendering process and avoiding the untimely state synchronization problem caused by scattered polling in existing technologies. This significantly improves the client's response speed and real-time performance, enhancing the user experience.

[0039] Based on the above embodiments, please also refer to Figure 3 , Figure 3 A flowchart of a method for processing various special events to be processed based on event type and processing order is further provided for embodiments of this disclosure, wherein process 300 includes the following steps: Step 301: Determine the event type of the special event to be processed; The event type can include: window configuration class and image idle class, and the special events to be processed under the corresponding event type are: window configuration event (or latest window configuration event) and image idle event.

[0040] Step 302: In response to the existence of at least two pending special events, obtain the timestamps of each pending special event; This step is based on the existence of at least two pending special events. The purpose is for the aforementioned executing entities to extract the timestamp of each pending special event to clarify the occurrence of each special event, so as to arrange the execution in an orderly manner according to the occurrence of the event.

[0041] As can be seen from the above description of the two types of special events in the embodiments, when there are at least two special events to be processed, these special events to be processed will only have two situations: 1) one latest window configuration event and at least one image idle event; 2) at least two image idle events.

[0042] Step 303: Based on the event occurrence time shown by each timestamp of each special event to be processed, process each special event to be processed in the order of event occurrence according to the processing method corresponding to its event type.

[0043] Based on step 302, this step aims to have the aforementioned executing entity process each special event to be processed in the order of its occurrence, according to the event occurrence time represented by each timestamp of each special event to be processed, and in accordance with the processing method corresponding to the event type to which it belongs.

[0044] That is, based on the event occurrence time shown by each timestamp of each special event to be processed, the event occurrence order of each special event to be processed is determined (for example, in the order from first to last), and then each special event to be processed is processed in this order according to the processing method corresponding to its event type.

[0045] To facilitate understanding, an example is given below: Assume there are a total of 3 special events to be processed, with the timestamps in the following order: Image Idle Event A, Window Configuration Event, and Image Idle Event B. In the process, the execution entity will first process Image Idle Event A according to the processing method for Image Idle Events, then process Window Configuration Event according to the processing method for Window Configuration Events, and finally process Image Idle Event B according to the processing method for Image Idle Events.

[0046] The reason why they can be executed sequentially according to the time order shown by the timestamp is that the image idle event is used to determine the idle image resources. However, for the image idle resources determined by the image idle event corresponding to the current frame, they only participate in the allocation when the window configuration event corresponding to the subsequent frame needs image resources, and are not directly used for the allocation of image resources needed by the window configuration event of the current frame. Therefore, for the current frame, the two types of special events can be executed sequentially according to the original time order.

[0047] In cases where there are multiple special events to be processed, this embodiment provides a specific implementation method through steps 301-303: first, the event type and the timestamp of each event are determined, and then each event is processed in turn according to the order of occurrence determined by the timestamp.

[0048] For a clearer understanding of how to handle each specific type of event, please refer to the following detailed explanation: For the window configuration event (or latest window configuration event), the new window size and resource rebuild flag can be extracted from the window configuration event. Then, the old swap chain is destroyed according to the resource rebuild flag, and a new swap chain is rebuilt using image resources that match the new window size.

[0049] For the window configuration change event (XCB_PRESENT_CONFIGURE_NOTIFY), the processing steps are as follows: First, extract the new window width and height information (such as event->width and event->height) from the event and store it in the client's local variables (such as current_window_width and current_window_height); then, set a resource rebuild flag (such as need_rebuild_swapchain = true), indicating that the swap chain needs to be recreated before the current frame is rendered. The swap chain must be rebuilt after the window size changes, otherwise the image resources cannot adapt to the new window.

[0050] For image idle events, we can first extract the identifier representing pixel mapping information from the image idle event, then match the corresponding image resource object in the image resource list according to the identifier, and finally mark the status of the image resource object as available.

[0051] For the image idle event (XCB_PRESENT_IDLE_NOTIFY), the processing steps are as follows: extract the pixmap identifier representing the image resource from the event (e.g., event->pixmap), then search for the image object that matches the identifier in the client's image resource list (e.g., image_list) (each image object is associated with a pixmap); once found, mark the status of the image object as available (e.g., image->status = IDLE), indicating that the resource has been released by the X server and the current frame can be reused.

[0052] After the above two types of events have been processed separately, they can be merged as follows: For example, before the current frame is rendered, the client will first check the resource reconstruction flag. If the flag is true, the old swap chain will be destroyed first, and a new set of image resources will be created according to the new window size (such as create_swapchain(current_window_width, current_window_height)) to ensure that the image resources match the window size. Then, the client will select an image with an available status from the image resource list (such as find_idle_image(image_list)). If there is an available image, the resource will be reused directly as the rendering target of the current frame. If not, a new image resource needs to be created (but this situation has an extremely low probability of occurring due to the processing of image idle events).

[0053] To deepen the understanding of how the client generates and sends a window configuration request, and how the X server processes the window configuration request to ultimately obtain the window configuration event, this embodiment provides a specific implementation method: First, the aforementioned execution entity receives at least one window adjustment operation initiated for the target window and can send at least one window configuration request to the X server. This at least one window adjustment operation occurs after the rendering operation of the previous image frame and before the rendering operation of the current image frame (i.e., within the processing interval). At this time, for the window configuration request received within this processing interval, the X server will only process the latest window configuration request (i.e., the window configuration request with the latest timestamp) to generate a unique window configuration event (i.e., the latest window configuration event described in the above embodiment), and wait for it to be sent as a special event to be processed. Then, the aforementioned execution entity can initiate a special event query operation with the X server before the current image frame is rendered, and obtain the latest window configuration event and / or at least one image idle event returned by the X server.

[0054] For ease of understanding, this embodiment also provides an image rendering system, including: The client is used to initiate a special event query operation to the X server before rendering each image frame. The X server is used to query operations based on received special events and return the special events to be processed accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame to the client. The client is also used to process various special events to be processed and to render the current image frame based on the processing results.

[0055] This image rendering system demonstrates how the client and X server, which constitute the X11 graphics system architecture, interact to query and process special events, thereby completing the rendering of the current image frame.

[0056] Furthermore, considering that users on the client side might continuously adjust the window size by dragging the edge of the selected target window during the two-frame rendering period, resulting in multiple window adjustment operations, the client will simultaneously send multiple window configuration requests to the X server during the two-frame rendering period (the number of window configuration requests may be the same as or slightly different from the number of window adjustment operations). However, after these multiple window configuration requests arrive at the X server, the X server will first determine which one should be generated as the final, unique window configuration event. That is, the X server will not send window configuration events to the client in the same number as the number of window configuration requests received. Instead, the X server will determine the latest window configuration request based on the timestamp of each window configuration request, and then generate a unique window configuration event to be sent based on the latest window configuration request. In this case, the system will behave as follows: The client is also configured to send at least one window configuration request to the X server in response to receiving at least one window adjustment operation initiated for the target window, wherein the at least one window adjustment operation occurs after the rendering operation of the previous image frame and before the rendering operation of the current image frame. The X server is also used to generate a latest window configuration event for the latest window configuration request in at least one received window configuration request. The X server is specifically used to query operations based on received special events and return the latest window configuration events and / or at least one image idle event accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame to the client. The client is specifically used to process the latest received window event and / or at least one image idle event, and to render the current image frame based on the processing results.

[0057] Based on the description of traditional solutions in the background section, it is clear that the traditional method of synchronizing the client and server by frequently calling `xcb_poll_for_special_event` to wait for the X server's `Idle Notify` event has significant performance drawbacks. In scenarios such as frequent window resizing or high frame rate rendering, this method triggers a large number of unnecessary polling operations, leading to increased CPU utilization, wasted system resources, and potentially increased operation latency due to blocking and waiting, affecting application responsiveness and overall energy efficiency. Furthermore, this mechanism adopts a conservative strategy of "polling after every operation," lacking intelligent judgment of the server's actual load and command processing progress, resulting in "over-synchronization" and further exacerbating performance overhead.

[0058] Therefore, to solve the above-mentioned technical problems, this embodiment also provides an optimized synchronization mechanism that can effectively reduce the number of calls to xcb_poll_for_special_event, reduce system overhead, and improve graphics rendering efficiency and system response performance, while ensuring that the client and X server are correctly synchronized.

[0059] Please see Figure 4 , Figure 4 This is a flowchart of a performance optimization method for reducing the XCB event polling frequency proposed in this invention. It is mainly used to solve the performance bottleneck, logic dispersion and synchronization delay problems caused by multiple calls to xcb_poll_for_special_event() to query different types of events (such as XCB_PRESENT_CONFIGURE_NOTIFY and XCB_PRESENT_IDLE_NOTIFY) in the prior art.

[0060] Figure 4 This describes the complete process in a graphics system based on the X11 protocol and the Present extension, in which the client obtains all special events to be processed by calling xcb_poll_for_special_event() once during each frame rendering process, and uniformly parses and processes window size changes and image idle states, thereby efficiently managing Swapchain and image resources and improving overall rendering performance and synchronization efficiency.

[0061] Figure 4 The flowchart shown starts from "the beginning of the frame rendering loop". First, a unified call to `xcb_poll_for_special_event()` retrieves all currently pending special events (such as events from the X Server's event queue). Then, these returned events are iterated and categorized, identifying the following two key events based on their event type: The XCB_PRESENT_CONFIGURE_NOTIFY event indicates that the window size has changed. After receiving this event, the client records the new window width and height information and sets an internal flag to determine whether it is necessary to recreate the Swapchain and its multiple Image resources that match the window size.

[0062] The XCB_PRESENT_IDLE_NOTIFY event indicates that a previously submitted Image is no longer being used by the XServer (i.e., it is in an idle state). The client parses the pixmap field in this event, matches the corresponding Image, and marks its state as "idle" so that it can be reused in subsequent rendering.

[0063] After completing the unified analysis of events, the process enters the state handling and resource management phase, which mainly includes two core logical branches: If a window size change is detected (i.e., the window_resized flag is true), the client will perform the destruction and reconstruction operation of the Swapchain, and initialize a new set of Image resources according to the new window size to ensure correct adaptation for subsequent rendering and display. If an Image is detected to be in an idle state (identified by the IDLE_NOTIFY event), the Image is marked as reusable (IDLE) and used preferentially in subsequent image selection logic to avoid invalid waiting or duplicate allocation. At the same time, its status is updated to "free" for use in the current frame drawing.

[0064] Finally, the client performs drawing operations (such as CPU / GPU rendering) on ​​the selected Image and submits the rendering result to the X Server for display via the Present extension. After submission, the Image will be used by the X Server and will trigger the IDLE_NOTIFY event again upon completion, forming a complete event and state management loop.

[0065] The flowchart returns to the starting point through the "next frame loop" node, indicating that the event polling, state handling and image rendering mechanism is driven by each frame, which can continuously and efficiently respond to window changes, manage the image lifecycle, and ensure the synchronization of rendering and display.

[0066] In summary, this embodiment proposes an event-driven, centralized polling XCB synchronization optimization mechanism, aiming to significantly reduce the call frequency of xcb_poll_for_special_event, thereby reducing CPU overhead and improving graphics rendering efficiency and system response performance. It has the following key improvements and corresponding technical effects: 1) Centralized polling mechanism: one polling, multiple information acquisitions By merging multiple polling operations that were originally scattered across several critical paths (such as checking window changes and pixmap idle status) into a single polling point after the `xcb_present` operation ends and before the next drawing begins, `xcb_poll_for_special_event` is called once at this point to handle various special events such as `XCB_PRESENT_CONFIGURE_NOTIFY` and `XCB_PRESENT_IDLE_NOTIFY`, and to record relevant status information (such as window size change flags and pixmap idle status) for use by subsequent logic. This mechanism achieves "one poll, multiple synchronizations," significantly reducing the polling frequency.

[0067] 2) Event-based asynchronous resource status update mechanism

[0068] An asynchronous resource state management strategy is introduced: when xcb_poll_for_special_event returns the XCB_PRESENT_IDLE_NOTIFY event, the system compares the pixmap handle in the event with the pixmap associated with the currently rendered image. If they match, the internal state of that image is marked as "idle" (busy=false), instead of re-polling every time an image is retrieved.

[0069] This embodiment optimizes performance by refactoring the timing of `xcb_poll_for_special_event` calls and employing a collaborative mechanism of "event triggering + centralized polling." This minimizes the number of polling calls while ensuring correct synchronization between the client and the X server's rendering. This solution is particularly suitable for high-frame-rate graphics applications, frequent window interaction scenarios, and energy-sensitive embedded systems, demonstrating significant technological advancements and practical value.

[0070] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of an image rendering apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0071] like Figure 5As shown, the image rendering apparatus 500 of this embodiment may include: a special event query operation initiation unit 501, a special event acquisition unit 502, and a special event processing unit 503. The special event query operation initiation unit 501 is configured to initiate a special event query operation to the X server before rendering each image frame; the special event acquisition unit 502 is configured to acquire the pending special events returned by the X server in response to the received special event query operation, which are the special events accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame; the special event processing unit 503 is configured to process each pending special event and render the current image frame according to the processing result.

[0072] In this embodiment, the specific processing and technical effects of the special event query operation initiation unit 501, special event acquisition unit 502, and special event processing unit 503 in the image rendering apparatus 500 can be referred to respectively. Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiments will not be repeated here.

[0073] In some other optional implementations of this embodiment, the special event handling unit 503 includes a processing subunit configured to process each special event to be processed. The processing subunit includes: The event type determination module is configured to determine the event type of the special event to be processed; the event types include: window configuration class and image idle class, and the special events to be processed under the corresponding event types are: latest window configuration event and image idle event, respectively; The event type handling module is configured to process special events according to the handling method corresponding to their respective event types.

[0074] In some other optional implementations of this embodiment, the event type processing module is further configured to: In response to the existence of at least two pending special events, obtain the timestamps of each pending special event; Based on the timestamps of each pending special event, each pending special event is processed in the order of its occurrence according to the processing method corresponding to its event type.

[0075] In some other optional implementations of this embodiment, the image rendering apparatus 500 may further include: The window configuration request sending unit is configured to send at least one window configuration request to the X server in response to receiving at least one window adjustment operation initiated for the target window; wherein the at least one window adjustment operation occurs after the rendering operation of the previous image frame and before the rendering operation of the current image frame; Correspondingly, the special event acquisition unit 502 is further configured to acquire the latest window configuration event and / or at least one image idle event accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame, returned by the X server in response to the received special event query operation; wherein, the latest window configuration event is obtained by the X server processing the latest window configuration request in at least one received window configuration request.

[0076] In some other optional implementations of this embodiment, the event type processing module is further configured to: For the latest window configuration event, extract the new window size from the latest window configuration event and set the resource rebuild flag for the new window size; The old swap chain is destroyed based on the resource reconstruction flag, and a new swap chain is reconstructed using image resources that match the new window size.

[0077] In some other optional implementations of this embodiment, the event type processing module is further configured to: For image idle events, extract identifiers representing pixel mapping information from the image idle events; Match the corresponding image resource object in the image resource list based on the identifier; Mark the image resource object as available.

[0078] This embodiment exists as a device embodiment corresponding to the above method embodiment. Addressing the technical problems of high CPU utilization, wasted system resources, response delays, and excessive synchronization caused by frequent special event queries initiated by the client in the asynchronous communication mechanism between the client and the X server in the existing X11 graphics system architecture, the image rendering device provided in this disclosure, by initiating a special event query operation only once before rendering each image frame, can obtain all pending special events accumulated from the previous image frame rendering operation to the current image frame rendering operation returned by the X server in one go. This centralizes the special event query, significantly reduces the number of system calls, and lowers the CPU load on the client. Simultaneously, centralized processing of all obtained pending special events ensures that the current frame rendering is based on the latest window state and image resource state, optimizes the continuity of the rendering process, avoids the problem of untimely state synchronization caused by scattered polling in the prior art, significantly improves the client's response speed and real-time performance, and enhances the user experience.

[0079] According to embodiments of the present disclosure, the present disclosure also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the image rendering method described in any of the above embodiments when executed.

[0080] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that enable a computer to implement the image rendering method described in any of the above embodiments when executed.

[0081] According to embodiments of this disclosure, this disclosure also provides a computer program product that, when executed by a processor, can implement the image rendering method described in any of the above embodiments.

[0082] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0083] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0084] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0085] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as image rendering methods. For example, in some embodiments, the image rendering method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the image rendering method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the image rendering method by any other suitable means (e.g., by means of firmware).

[0086] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0087] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0088] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0089] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0090] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0091] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0092] To address the technical issues of high CPU utilization, wasted system resources, response latency, and excessive synchronization caused by frequent special event queries from the client in the asynchronous communication mechanism between the client and the X server in the existing X11 graphics system architecture, the image rendering solution provided in this disclosure initiates a special event query operation to the X server only once before rendering each image frame. This allows for the centralized acquisition of all pending special events accumulated from the rendering operation of the previous image frame to the rendering operation of the current image frame, thus significantly reducing the number of system calls and lowering the CPU load on the client. Simultaneously, centralized processing of all acquired pending special events ensures that the current frame rendering is based on the latest window state and image resource state, optimizing the continuity of the rendering process and avoiding the untimely state synchronization problem caused by scattered polling in existing technologies. This significantly improves the client's response speed and real-time performance, enhancing the user experience.

[0093] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0094] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An image rendering method, characterized in that, The method, applied to a client communicating with an X server, includes: Before rendering each image frame, a special event query operation is initiated to the X server. Obtain the special events to be processed accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame, returned by the X server in response to the received special event query operation. The special event to be processed is processed, and the current image frame is rendered based on the processing result.

2. The method according to claim 1, characterized in that, The processing of each of the aforementioned special events to be processed includes: Determine the event type of the special event to be processed; wherein, the event type includes: window configuration class and image idle class, and the special events to be processed under the corresponding event types are: latest window configuration event and image idle event, respectively; The special events to be processed are processed according to the processing method corresponding to their respective event types.

3. The method according to claim 2, characterized in that, The process of handling the special event to be processed according to the processing method corresponding to its event type includes: In response to the existence of at least two of the aforementioned special events to be processed, obtain the timestamps of each of the aforementioned special events to be processed; Based on the event occurrence time shown by each timestamp of the special event to be processed, each special event to be processed is processed in the order of occurrence according to the processing method corresponding to its event type.

4. The method according to claim 1, characterized in that, The method further includes: In response to receiving at least one window adjustment operation initiated for the target window, at least one window configuration request is sent to the X server; wherein, the at least one window adjustment operation occurs after the rendering operation of the previous image frame and before the rendering operation of the current image frame; Correspondingly, obtaining the special events to be processed accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame, returned by the X server in response to the received special event query operation, includes: The X server retrieves the latest window configuration event and / or at least one image idle event accumulated between the rendering operation of the previous image frame and the rendering operation of the current image frame, as returned by the X server in response to a received special event query operation; wherein the latest window configuration event is obtained by the X server processing the latest window configuration request in the at least one received window configuration request.

5. The method according to any one of claims 2-4, characterized in that, The process of handling the special event to be processed according to the processing method corresponding to its event type includes: For the latest window configuration event, extract the new window size from the latest window configuration event, and set a resource rebuild flag for the new window size; The old swap chain is destroyed according to the resource reconstruction flag, and a new swap chain is reconstructed using image resources that match the new window size.

6. The method according to claim 2 or 3, characterized in that, The process of handling the special event to be processed according to the processing method corresponding to its event type includes: For the image idle event, extract the identifier representing pixel mapping information from the image idle event; Match the corresponding image resource object in the image resource list according to the identifier; The image resource object is marked as available.

7. An image rendering apparatus, characterized in that, A client device used to communicate with an X server, the device comprising: The special event query operation initiation unit is configured to initiate a special event query operation to the X server before rendering each image frame. The special event acquisition unit is configured to acquire the special events to be processed accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame, returned by the X server in response to the received special event query operation. The special event processing unit is configured to process each of the special events to be processed and render the current image frame based on the processing results.

8. An image rendering system, characterized in that, include: The client is used to initiate a special event query operation to the X server before rendering each image frame. The X server is used to query operations based on received special events and return the special events to be processed accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame to the client. The client is also used to process each of the special events to be processed, and to render the current image frame based on the processing results.

9. The image rendering system according to claim 8, characterized in that, The client is also configured to send at least one window configuration request to the X server in response to receiving at least one window adjustment operation initiated for the target window, wherein the at least one window adjustment operation occurs after the rendering operation of the previous image frame and before the rendering operation of the current image frame. The X server is also configured to generate a latest window configuration event for the latest window configuration request in the at least one window configuration request received; The X server is specifically used to query operations based on received special events and return the latest window configuration event and / or at least one image idle event accumulated after the rendering operation of the previous image frame and before the rendering operation of the current image frame to the client. The client is specifically used to process the latest window event and / or at least one image idle event received, and to render the current image frame based on the processing result.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the image rendering method according to any one of claims 1-6.

11. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the image rendering method according to any one of claims 1-6.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the image rendering method according to any one of claims 1-6.

Images