Display method, electronic device, and computer readable medium

Abstract

The application relates to the computer technical field, in particular to a display method, an electronic device and a computer readable medium. In the case that the allocation service receives the application buffer request sent by a plurality of rendering threads, the allocation service can apply the buffer for each rendering thread in parallel. The allocation service can start to allocate the buffer for another rendering thread before the allocation of the buffer for one rendering thread is completed. Therefore, in the process of allocating the buffer for the plurality of rendering threads, the allocation service does not need to wait for the completion of the buffer application of one rendering thread before applying the buffer for the next rendering thread. Based on the method, the time required for each rendering thread to wait for extracting the buffer can be shortened, the display interface is prevented from being stuck or jumping frames due to the long waiting time, the smoothness of the display interface is improved, and the user experience is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a display method, an electronic device, and a computer-readable medium. Background Technology

[0002] In the scenario of generating an application's user interface, the rendering thread corresponding to that application first requests a buffer from the allocator service to draw and render the application's interface content. Then, the rendering thread draws and renders the application interface into the requested buffer. Next, the process in the electronic device used to composite the display interface (e.g., SurfaceFlinger) can composite the application interfaces in the buffers corresponding to different applications to obtain a complete display interface.

[0003] In some scenarios, such as when an application switches between foreground and background, or when the window size and / or amount of data to be displayed change, the application's rendering thread needs to re-request buffers from the allocation service for drawing and rendering the interface content. If multiple applications on an electronic device request buffers from the allocation service, the allocation service will allocate buffers sequentially for each application's interface. That is, after allocating a buffer for one application's interface, it will allocate a buffer for the next application. This can cause applications that request buffers later in the order to wait longer, thus increasing the time it takes for that application to draw and render its interface, and consequently causing stuttering or frame drops in the display process.

[0004] For example, see Figure 1 The screen of phone 10A displays the chat interface 100a of an instant messaging application. As the user swipes up on the screen of phone 10A, the phone gradually switches from displaying the chat interface 100a to displaying the multitasking interface 100b. This interface switching process can be understood as being displayed by the desktop application process.

[0005] As the user swipes up, the window size of the instant messaging application's chat interface 100a changes, and the desktop application switches from running in the background to running in the foreground. Therefore, both the instant messaging application and the desktop application request a new buffer from the phone's allocation service. If the allocation service allocates a buffer for the desktop application first, it may cause a rendering delay in the instant messaging application's chat interface 100a, resulting in a stuttering effect as the chat interface 100a's window gradually shrinks. Conversely, if the allocation service allocates a buffer for the instant messaging application first, it may cause a rendering delay in the multitasking interface 100b, resulting in a stuttering effect in the desktop application when switching from the chat interface 100a to the multitasking interface 100b. Summary of the Invention

[0006] This application provides a display method, an electronic device, and a computer-readable medium that can avoid stuttering, frame drops, and other phenomena when an electronic device displays multiple application interfaces simultaneously.

[0007] In a first aspect, this application provides a display method applied to an electronic device. The display method includes: detecting a first instruction to display a first application interface; allocating a first buffer for a first rendering thread of the first application interface and rendering the first application interface based on the first buffer; detecting a switching instruction to switch the display of the first application interface to display M second application interfaces, wherein M is greater than or equal to 2; and allocating multiple second buffers in parallel for N second rendering threads corresponding to the M second application interfaces, and rendering multiple second application interfaces based on the multiple second buffers respectively, wherein M is less than or equal to N.

[0008] Here, the first application interface can be the display interface of a first application. The first instruction to display the first application interface can be any system instruction and / or user operation that enables the first application to display the first application interface. No limiting description is provided for the first instruction here. For example, the first rendering thread can be the rendering thread of the first application, and the first rendering thread can be used to render and draw the first application interface. The M second application interfaces can be application interfaces of one or more applications. It is understood that different second application interfaces can belong to the same application or different application interfaces. No limiting description is provided for the application to which the second application interfaces belong.

[0009] This application does not impose any restrictive description on the correspondence between the M second application interfaces and the N second rendering threads. For example, M can be equal to N. Specifically, each of the M second application interfaces can correspond to one second rendering thread, and each second rendering thread can be used to render one second application interface. Alternatively, M can be greater than N, in which case one second rendering thread can be used to render multiple second application interfaces. Furthermore, M can be less than N; specific examples of this can be found in the detailed description below and will not be repeated here.

[0010] Furthermore, the first buffer and the second buffer can be a single buffer or multiple buffers used to implement buffer rotation based on a buffer rotation mechanism. For example, one or more corresponding second buffers in M ​​second application interfaces can be multiple buffers. Here, no restrictive description is made regarding the number of first buffers corresponding to the first application interface, or the number of second buffers corresponding to each second application interface. If the first buffer is multiple buffers, generally speaking, the first rendering thread can serially request the multiple buffers included in the first buffer. Correspondingly, if the second buffer corresponding to the second application interface is multiple buffers, generally speaking, the second rendering thread can serially request the multiple buffers included in the second buffer.

[0011] It is understandable that a rendering thread's serial request for multiple buffers does not affect the electronic device's ability to allocate buffers in parallel for multiple rendering threads. For details, please refer to the following section. Figure 2b The details of how the allocation service allocates buffer 101 and buffer 200 in parallel based on the first allocation buffer thread 12 and the second allocation buffer thread 22 are not elaborated here.

[0012] In one example, the M second application interfaces can be the application interfaces to be displayed by the first application, the second application, and the third application (hereinafter referred to as the third application). Correspondingly, the N second rendering threads can be rendering thread 11 of the first application, rendering thread 21 of the second application, and rendering thread 31 of the third application (hereinafter referred to as the third application). Correspondingly, the multiple second buffers can be buffer 100, buffer 200, and buffer 300 (hereinafter referred to as the buffers).

[0013] Based on the above, since the electronic device allocates buffers for displaying M second application interfaces to N second rendering threads in parallel, each second rendering thread does not need to wait sequentially for the electronic device to respond to its buffer request after requesting a buffer. This significantly shortens the latency between the second rendering thread sending a buffer request and retrieving the buffer, and reduces the waiting time required before it can draw and display content based on the buffer. It can be understood that after multiple rendering threads send buffer request requests, because the electronic device responds to each request in parallel, each rendering thread can retrieve the buffer and begin drawing work in a shorter time. Therefore, this effectively avoids problems such as application interface display stuttering and frame drops caused by excessive latency in waiting for buffer allocation when displaying multiple application interfaces simultaneously.

[0014] In one possible implementation of the first aspect above, M is 2, the first application interface U1 and the second application interface U2 among the M second application interfaces are the interfaces of the first application; and the M second application interfaces also include the second application interface U3 of the second application.

[0015] Here, the electronic device can, based on a switching command, add a second application interface to the existing display of the first application interface, thus displaying two application interfaces simultaneously. The first application interface U1 displayed before receiving the switching command can be the second application interface U2 displayed after the switch, and the second application interface U2 displayed after the switch can also be different from the first application interface U1 displayed before the switch. No restrictive descriptions are made regarding the application interfaces displayed before and after the switch. The second rendering thread of the second application interface U2 and the second rendering thread of the second application interface U3 displayed after the switch may both request buffers. Therefore, the electronic device can allocate the buffers required for displaying the second application interface U2 and the second application interface U3 in parallel. This shortens the time required to display the second application interface U2 and the second application interface U3, avoiding problems such as application interface display stuttering and frame drops.

[0016] Specifically, the reason why the second application interface U2 displayed after switching needs to re-allocate the buffer may be that the window size of the first application interface U1 displayed before switching is significantly different from that of the second application interface U2 displayed after switching, and / or that the amount of data to be displayed in the first application interface U1 displayed before switching is significantly different from that in the second application interface U2 displayed after switching. The reason why the second application interface U3 displayed after switching needs to re-allocate the buffer may be that the second application is running for the first time, or that the second application has switched from background to foreground running. It is understood that this application does not provide restrictive explanations regarding the specific reasons for the second application interface U2 and the second application interface U3 re-allocating the buffer.

[0017] In one possible implementation of the first aspect above, the switching instruction is used to instruct any of the following: the second application interface U2 and the second application interface U3 to be displayed in split screen; the second application interface U2 to be displayed in full screen and the second application interface U3 to be displayed in a floating window; the second application interface U3 to be displayed in full screen and the second application interface U2 to be displayed in a floating window.

[0018] Here, the electronic device can simultaneously display the second application interface U2 and the second application interface U3 in the form of split-screen display, or by overlaying one second application interface on top of another based on a floating window. This application does not make any restrictive descriptions on the specific display methods of the second application interface U2 and the second application interface U3.

[0019] In one possible implementation of the first aspect above, the switching instruction is used to instruct the display of a multitasking interface on the desktop. The multitasking interface includes M second application interfaces, where M is less than N, and the N second rendering threads include the M second rendering threads corresponding to the second application interfaces of the M second applications and the second rendering threads corresponding to the desktop application.

[0020] Here, the multitasking interface can be used to display the second application interfaces of all second applications running in the background. The multitasking interface can be the application interface of a desktop application on an electronic device. For example, there can be M second applications running in the background of the electronic device, and correspondingly, the multitasking interface can also include M second application interfaces. Therefore, it can be understood that to display the multitasking interface, M second rendering threads of the M background applications are needed to render their respective second application interfaces, and at least one second rendering thread of the desktop application is needed to render the multitasking interface. Therefore, it can be understood that when displaying the multitasking interface, the number M of second application interfaces is less than the number N of second rendering threads.

[0021] In one possible implementation of the first aspect above, the second rendering thread corresponding to the desktop application includes: a second rendering thread corresponding to the multitasking interface; or, a second rendering thread corresponding to the multitasking interface and a second rendering thread corresponding to the negative one screen interface.

[0022] In one example, because the desktop application and the negative one screen application are closely related—for example, when a user is using the desktop application to display the multitasking interface or the desktop interface, there is a high probability that they will switch to the negative one screen interface based on user actions such as swiping—most electronic device manufacturers implement a strategy whereby, when the desktop application's rendering thread re-allocates a buffer, the negative one screen application's rendering thread also requests a buffer to prepare for displaying the negative one screen interface. Therefore, under this strategy, the second rendering thread of the desktop application can include both the second rendering thread of the desktop application corresponding to the multitasking interface and the second rendering thread of the negative one screen application corresponding to the negative one screen interface.

[0023] Here, the negative one screen can be a system application interface that includes a series of customizable widgets, news summaries, quick actions, a search box, or other services. Users can access the negative one screen by swiping on the desktop interface.

[0024] In another example, when an electronic device displays a multitasking interface, it may simultaneously display a desktop interface; see the following for details. Figure 1 and Figure 5The diagram illustrates a multitasking interface that can be overlaid on the desktop interface. Based on this display method, the multitasking interface can have only one second rendering thread, which simultaneously renders both the overlaid multitasking interface and the desktop interface. Alternatively, the multitasking interface can have two second rendering threads, one for rendering the multitasking interface and the other for rendering the desktop interface.

[0025] In one possible implementation of the first aspect above, detecting a switching instruction to switch the display of a first application interface to the display of M second application interfaces includes: detecting a user's swipe-up operation at the bottom of the electronic device screen and detecting the switching instruction.

[0026] Here, a switching command for displaying a multitasking interface can be a swipe-up operation by the user at the bottom of the electronic device screen.

[0027] In one possible implementation of the first aspect above, multiple second buffers are allocated in parallel for N second rendering threads corresponding to M second application interfaces, including: receiving requests for buffers from N second rendering threads, creating corresponding allocation threads for each of the N second rendering threads; and allocating buffers in parallel for the N second rendering threads based on the N allocation threads.

[0028] In one example, the M second application interfaces can be the application interfaces to be displayed by the first application, the second application, and the third application (hereinafter referred to as the third application). Correspondingly, the N second rendering threads can be rendering thread 11 of the first application, rendering thread 21 of the second application, and rendering thread 31 of the third application (hereinafter referred to as the third application). Correspondingly, the multiple second buffers can be buffer 100, buffer 200, and buffer 300 (hereinafter referred to as the buffers). The allocation threads can be buffer allocation threads (hereinafter referred to as the buffer allocation threads), and the N allocation threads can be the first buffer allocation thread 12, the second buffer allocation thread 22, and the third buffer allocation thread 32 (hereinafter referred to as the buffer allocation threads).

[0029] Therefore, based on the display method provided in this application, buffers 100, 200, and 300 can be allocated in parallel for the rendering thread 11 of the first application, the rendering thread 21 of the second application, and the rendering thread 31 of the third application. This avoids problems such as stuttering and frame skipping when the electronic device displays the application interfaces of the first, second, and third applications simultaneously.

[0030] In one possible implementation of the first aspect above, the electronic device includes a first service for allocating buffers. The first service includes a first interface, and allocates buffers in parallel for N second rendering threads based on N allocation threads, including: a first allocation thread among the N allocation threads calling the first service to allocate a buffer for the second rendering thread corresponding to the first allocation thread during a first allocation period; and a second allocation thread among the N allocation threads calling the first service to allocate a buffer for the second rendering thread corresponding to the second allocation thread during a second allocation period; wherein the first allocation period and the second allocation period overlap or partially overlap.

[0031] Here, the first service can be the allocation service mentioned below, such as Android. TM The system's vendor.qti.hardware.display.allocator-service. The first service can respond to a buffer request sent by the rendering thread, create a corresponding buffer allocation thread for the rendering thread, and allocate a buffer for the rendering thread corresponding to the buffer allocation thread based on the buffer allocation thread's call to the first interface.

[0032] For example, a first service may respond to buffer request requests sent by N second rendering threads by creating N corresponding allocation threads for the N second rendering threads, and allocate buffers for the N second rendering threads corresponding to the N allocation threads based on the calls to the first interface by the N allocation threads. The first interface may be the interface used for buffer allocation in the allocation service described below, such as the AllocBuffer interface. The first allocation thread may be any one of the N allocation threads, and the second allocation thread may be any one of the N allocation threads that is different from the first allocation thread.

[0033] The first allocation period for the first allocation thread to allocate the buffer may include the time period from the start of buffer allocation to the completion of buffer allocation. The first allocation thread is described below. Figure 2a Taking the first allocation buffer thread 12 as an example, the first allocation period can be from time t05 to time t06 of the allocation buffer 100.

[0034] It is understandable that, based on N allocation threads allocating buffers in parallel for N second rendering threads, at least the first allocation period of the first allocation thread overlaps or partially overlaps with the second allocation period of the second allocation thread. In this case, the allocation service can allocate two buffers simultaneously. Alternatively, at most, all N allocation periods of the N allocation threads can overlap or partially overlap; in this case, the allocation service can allocate N buffers simultaneously. No restrictions are placed on the number of buffers allocated in parallel.

[0035] In one possible implementation of the first aspect above, the first allocation period coincides with or partially coincides with the second allocation period, including any of the following: the start time of the first allocation period is the same as the start time of the second allocation period and / or the end time of the first allocation period is the same as the end time of the second allocation period; the start time of the first allocation period is between the start time and the end time of the second allocation period; the end time of the first allocation period is between the start time and the end time of the second allocation period.

[0036] Here, no restrictive explanation is given regarding the specific circumstances of the parallel allocation buffer. As long as at least two of the N allocation threads have overlapping allocation periods in terms of timing, including overlapping time points, the allocation service can be considered to be in the parallel allocation buffer.

[0037] In one possible implementation of the first aspect described above, the first service further includes a first lock, wherein the scope of the first lock does not include the first interface, and the first lock is used to prevent the first variable in the first service from being read and written concurrently.

[0038] Here, the first lock can be `buffer_lock` in `vendor.qti.hardware.display.allocator-service`. The first variable can be the `dma_legacy_dev_fd` variable.

[0039] Taking `vendor.qti.hardware.display.allocator-service` as the first service, `vendor.qti.hardware.display.allocator-service` as the first interface, and `vendor.qti.hardware.display.allocator-service` as the first lock, `vendor.qti.hardware.display.allocator-service` as the first lock, because the `AllocBuffer` interface is within the scope of `buffer_lock`, it can only be called serially by the buffer allocation threads. That is, only after one buffer allocation thread has completed allocating the buffer can another buffer allocation thread call the `AllocBuffer` interface. Therefore, by setting the `AllocBuffer` interface outside the scope of `buffer_lock`, it can be called in parallel by multiple buffer allocation threads.

[0040] It is understandable that by using the above method, the first service can allocate multiple buffers in parallel, thereby avoiding the phenomenon of lag and frame drops when displaying multiple application interfaces.

[0041] In one possible implementation of the first aspect described above, the first variable is located in the first interface, wherein the first variable is a local variable.

[0042] Continuing the previous example, since the `dma_legacy_dev_fd` variable in the interface is prohibited from concurrent read and write operations, after setting the `AllocBuffer` interface outside the scope of `buffer_lock`, to prevent concurrent read and write operations on the `dma_legacy_dev_fd` variable, it can be set to a local variable type. It can be understood that for a local variable type `dma_legacy_dev_fd`, each thread and / or module calling the `AllocBuffer` interface has a corresponding `dma_legacy_dev_fd` variable value, and modifications to this variable value by different threads and / or modules will not affect each other. Therefore, concurrent read and write operations on the `dma_legacy_dev_fd` variable, which is located outside the scope of `buffer_lock`, can be effectively avoided. In this way, buffer allocation anomalies caused by concurrent read and write operations on the `dma_legacy_dev_fd` variable are prevented, thereby ensuring that the M second application interfaces can be displayed correctly.

[0043] In one possible implementation of the first aspect above, the first interface includes a first global set, wherein the first global set includes all variable values ​​of a first variable of local variable type; and when the first allocation buffer thread calls the first interface during destructing, all variable values ​​of the first variable are cleared based on the first global set.

[0044] Continuing the previous example, since each thread and / or module calling the AllocBuffer interface needs to clear the dma_legacy_dev_fd variable value during destruction, for example, the thread allocating the buffer needs to clear the dma_legacy_dev_fd variable value after completing the buffer allocation. Therefore, after setting the dma_legacy_dev_fd variable to a local variable type, a globally scoped collection can be set in the AllocBuffer interface. For example, a set collection can be set in the AllocBuffer interface to store all dma_legacy_dev_fd variable values. Then, when the thread and / or module calling the AllocBuffer interface destroys the buffer, they can globally clear the dma_legacy_dev_fd variable value by clearing this collection. This prevents buffer allocation anomalies caused by the dma_legacy_dev_fd variable not being globally cleared during destruction, thus ensuring that the M secondary application interfaces can be displayed correctly.

[0045] In a second aspect, this application provides an electronic device, including: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by one or more processors, cause the electronic device to perform the display method provided by the first aspect and various possible implementations of the first aspect.

[0046] Thirdly, this application provides a computer-readable medium storing instructions that, when executed on a computer, cause the computer to perform the display methods provided by the first aspect and various possible implementations of the first aspect.

[0047] Fourthly, this application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the first aspect described above and various possible implementations of the first aspect, providing a display method.

[0048] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant descriptions in the first aspect and various possible implementations of the first aspect, which will not be repeated here. Attached Figure Description

[0049] Figure 1 The diagram shown is a scenario where multiple applications request a buffer from an allocation service, as provided in this application.

[0050] Figure 2a The diagram shown is a timing illustration of multiple applications serially requesting buffers from an allocation service, as provided in this application.

[0051] Figure 2b The figure shown is a timing diagram illustrating multiple applications requesting buffers from an allocation service in parallel, according to an embodiment of this application.

[0052] Figure 2c The diagram shown is a timing illustration of another method provided in this application for multiple applications to serially request a buffer from an allocation service.

[0053] Figure 2d The figure shown is a timing diagram illustrating another instance of multiple applications requesting buffers from the allocation service in parallel, as provided in an embodiment of this application.

[0054] Figure 2e The figure shown is a timing diagram illustrating another instance of multiple applications serially requesting a buffer from an allocation service, as provided in this application.

[0055] Figure 2f The figure shown is a timing diagram illustrating another instance of multiple applications requesting buffers from an allocation service in parallel, as provided in an embodiment of this application.

[0056] Figure 3 The diagram shown is a schematic representation of a process by which an allocation service allocates buffers to multiple applications in parallel, according to an embodiment of this application.

[0057] Figure 4 The diagram shown is an interactive schematic of an allocation service that allocates buffers to multiple applications in parallel, according to an embodiment of this application.

[0058] Figure 5 The diagram shown is a schematic representation of a multitasking interface provided in an embodiment of this application;

[0059] Figure 6 The figure shown is a schematic diagram of the structure of an electronic device 1A provided in an embodiment of this application;

[0060] Figure 7 The diagram shown is a software structure block diagram of a handheld electronic device 1A provided in an embodiment of this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings and specific implementation methods.

[0062] It is understood that the display method provided in this application embodiment can be applied to electronic devices including but not limited to mobile phones, tablets, desktops, laptops, handheld computers, netbooks, augmented reality (AR) / virtual reality (VR) devices, smart TVs, smartwatches and other wearable devices, servers, mobile email devices, in-vehicle devices, portable game consoles, portable music players, e-reader devices, televisions with one or more processors embedded or coupled thereto, or other electronic devices capable of accessing networks.

[0063] It is understood that the aforementioned allocation service can create an allocation buffer thread to allocate buffers for the rendering thread of an application based on the allocation buffer request sent by the rendering thread corresponding to the application. When multiple applications of an electronic device request allocation buffers from the allocation service, the allocation service can create one or more allocation buffer threads to allocate buffers for multiple applications.

[0064] As discussed above, in scenarios where multiple applications on an electronic device simultaneously request buffers from the allocation service, the sequential allocation of buffers by the service may cause applications that request buffers later in the order to wait longer. This increases the time required for those applications to draw and render their interfaces, potentially leading to stuttering or dropped frames in the display process. It's understood that each rendering thread is in the process of requesting a buffer before it is actually allocated one. The simultaneous request for buffers by multiple applications can mean that the rendering threads of multiple applications are all in the process of requesting buffers for a certain period. Here, we do not specify the start and end times for each application's rendering thread to request buffers.

[0065] For example, Figure 2a This diagram illustrates the timing of the simultaneous request for buffers by the rendering threads of the first, second, and third applications in an electronic device.

[0066] Here, the rendering thread 11 of the first application, the rendering thread 21 of the second application, and the rendering thread 31 of the third application can all request a buffer from the electronic device's allocation service based on the initialization operation of the main thread of their respective applications. Furthermore, the allocation service can create a first buffer allocation thread 12 to allocate a buffer for the rendering thread 11 of the first application, a second buffer allocation thread 22 to allocate a buffer for the rendering thread 21 of the second application, and a third buffer allocation thread 32 to request a buffer for the rendering thread 31 of the third application. Here, the initialization operation of the application's main thread can occur during the application's first run, or when switching from background to foreground operation. Additionally, when the window size and / or the amount of data to be displayed by the application changes significantly, the application's rendering thread may also request a buffer from the electronic device's allocation service. Here, the scenario of requesting a buffer based on the initialization operation of the main thread is merely an example, and this application does not provide restrictive descriptions of specific scenarios in which the application's rendering thread requests a buffer.

[0067] For example, see Figure 2a From time t01 to t04, rendering threads 11, 21, and 31 are all in the process of requesting buffers, that is, Figure 2a This illustrates a scenario where a first application, a second application, and a third application simultaneously request a buffer from the allocation service. The following explanation details the buffer request process of the first application, taking the example of the first application requesting the buffer last.

[0068] Specifically, in this scenario, the main thread of the first application begins initialization at time t01. Based on this initialization, the rendering thread of the first application can request buffer 100 from the allocation service. However, because the interface used for buffer allocation in the allocation service (e.g., the AllocBuffer interface) is protected by a lock that restricts access to this interface to serial access (i.e., only one thread or module can access the interface at a time), each buffer allocation thread can only request buffers serially for its corresponding rendering thread. It should be understood that the lock used to restrict access to this interface to serial access can be a mutex, a spinlock, etc., and the type of lock is not specified here.

[0069] See Figure 2a The first buffer allocation thread 12 can only begin allocating buffer 100 for rendering thread 11 after the second buffer allocation thread 22 has completed allocating buffer 200 for rendering thread 21, and the third buffer allocation thread 32 has completed allocating buffer 300 for rendering thread 31. For example, if the second buffer allocation thread 22 and the third buffer allocation thread 32 complete the allocation of buffer 200 and buffer 300 sequentially at time t05, then the first buffer allocation thread 11 can only begin requesting buffer 100 at time t05.

[0070] Therefore, when rendering thread 11 extracts buffer 100 based on the drawing instruction issued by main thread 10 at time t03, since the first buffer allocation thread 12 has not yet completed the allocation of buffer 100, rendering thread 11 of the first application can only enter a state of continuously waiting to extract buffer 100 until the first buffer allocation thread 12 completes the allocation of buffer 100 at time t06. Only then can rendering thread 11 extract buffer 100 and start drawing work based on buffer 100 at time t06.

[0071] It is understandable that in this scenario, rendering thread 11 is always in the state of waiting to retrieve buffer 100 from time t03 to time t06. If the rendering thread 11 waits for too long to retrieve buffer 100, it will cause the display process of the application interface of the first application to be stuttered or have dropped frames.

[0072] To improve the efficiency of allocating buffers for application rendering threads, this application provides an explicit method in which the allocation service, upon receiving buffer allocation requests from multiple rendering threads (e.g., rendering threads of different applications), can allocate buffers for each rendering thread in parallel. In other words, the allocation service can begin allocating buffers for another rendering thread before it has finished allocating buffers for one.

[0073] In this way, the allocation service can allocate buffers for multiple rendering threads without waiting for one rendering thread to complete its buffer allocation before allocating buffers for the next. This reduces the time each rendering thread needs to wait to retrieve its buffer, avoiding display stuttering and frame skipping caused by excessive waiting time, improving the smoothness of the display and enhancing the user experience.

[0074] In some embodiments, to achieve cyclical use of buffers, applications may also request multiple buffers from the allocation service based on a buffer rotation mechanism. It is understood that in scenarios where applications need to serially request multiple buffers from the allocation service, if the allocation service uses the aforementioned... Figure 2a The illustrated scheme allocates buffers sequentially for different applications, which significantly increases the latency for responding to later buffer requests from each application. Therefore, the display method provided in this application, which allocates buffers to different applications in parallel, will significantly improve the smoothness of the display interface under the buffer rotation mechanism.

[0075] In some embodiments, the lock restricting the interface used for buffer allocation in the allocation service to serial access can be removed, or the scope of the lock can be adjusted so that different buffer allocation threads can call the interface in parallel to allocate buffers for different application rendering threads. For example, for Android... TM The AllocBuffer interface in the system can either remove the restriction that the interface can only be accessed serially by buffer_lock, or set the AllocBuffer interface outside the scope of buffer_lock.

[0076] Thus, exemplarily, Figure 2b The diagram illustrates the timing of the simultaneous allocation of buffers by the rendering threads of the first, second, and third applications in an electronic device based on the display method provided in this application.

[0077] See Figure 2bThe first buffer allocation thread 12, the second buffer allocation thread 22, and the third buffer allocation thread 32 can allocate buffers 100, 200, and 300 in parallel. For example, the second buffer allocation thread 22 can allocate buffer 200 for the rendering thread 21 of the second application between time t01 and time t04. Furthermore, even if the second buffer allocation thread 22 has not completed the allocation of buffer 200 before time t04, the third buffer allocation thread 32 can allocate buffer 300 in parallel for the rendering thread 31 of the third application before time t01, and complete the allocation of buffer 300 at time t05', before time t04.

[0078] Furthermore, at time t01, when the second buffer allocation thread 22 and the third buffer allocation thread 32 are allocating buffers in parallel, the first buffer allocation thread 12 receives a request from the rendering thread 11 of the first application to request buffer 100. Consequently, the allocation service can create the first buffer allocation thread 12, and the first buffer allocation thread 12 can start allocating buffer 100 for the rendering thread 11 at time t01.

[0079] Here, the first buffer allocation thread 12 can complete the allocation of buffer 100 at time t06'. Then, when the rendering thread 11 receives the drawing instruction sent by the main thread 10 of the first application at time t03, it can begin retrieving the buffer. However, since the first buffer allocation thread 12 completed the allocation of 100 at time t06' before time t03, the rendering thread 11 can retrieve the buffer 100 at time t03 and draw the interface content based on the buffer 100.

[0080] Understandable, in comparison to the aforementioned Figure 2a Rendering thread 11 is in a state of waiting to retrieve buffer 100 from time t03 to t06. Therefore, the excessively long wait time for retrieving buffer 100 may cause stuttering or frame drops in the interface display of the first application. However, based on the display method provided in this application, see... Figure 2b The rendering thread 11 can retrieve the buffer 100 and start drawing at time t03 upon receiving the drawing instruction, thus eliminating the need to wait for the buffer 100 to be retrieved. Clearly, the display method provided in this application effectively avoids problems such as stuttering and frame drops in the display process caused by excessively long waiting times for buffer retrieval.

[0081] Furthermore, one or more of rendering threads 11, 21, and 31 can also request multiple buffers based on a buffer rotation mechanism. Taking the example that rendering thread 11 also needs to request buffer 101 (not shown in the figure), rendering thread 11 completes the request for buffer 100 at time t06', and can then continue to request buffer 101 at any time after t06'. For example, the first buffer allocation thread 12 can start allocating buffer 101 at time t05' based on the request for buffer 101 sent by rendering thread 11. See also... Figure 2b At time t05', the second buffer allocation thread 22 has not yet completed the allocation of buffer 200. It can be understood that at this time, the allocation service is allocating buffers 101 and 200 in parallel based on the first buffer allocation thread 12 and the second buffer allocation thread 22. Here, it can be understood that the process of rendering thread 11 requesting buffers 100 and 101 is a serial request, but the process of the allocation service allocating buffers for different rendering threads is a parallel allocation. That is, each rendering thread can request multiple buffers serially, and the allocation service can allocate buffers for different rendering threads in parallel.

[0082] Furthermore, based on the aforementioned Figure 2a The diagram shown illustrates the serial allocation of buffers by the allocation thread. Figure 2c This diagram illustrates the execution timing of the serial buffer allocation process in a scenario where the buffer allocation thread may enter a non-running state.

[0083] For example, in some scenarios, if the electronic device is under heavy load with a large number of tasks executing simultaneously, the first buffer allocation thread 12, the second buffer allocation thread 22, and the third buffer allocation thread 32 may all enter a non-running state because their tasks have low priority and cannot preempt CPU resources. Here, the non-running state can be a runnable state. It can be understood that each buffer allocation thread can only allocate a buffer for the corresponding rendering thread when it is in the running state. Therefore, the time required for each buffer allocation thread to allocate a buffer may increase due to entering the runnable state.

[0084] For example, see Figure 2cThe second buffer allocation thread 22 and the third buffer allocation thread 32 may enter the runnable state multiple times, causing them to complete the allocation of buffers 200 and 300 sequentially until time t15. Consequently, the first buffer allocation thread 12 may not be able to start allocating buffer 100 until time t15. Furthermore, the first buffer allocation thread 11 may also experience a longer time required to allocate buffer 100 due to entering the runnable state multiple times. For example, if the first buffer allocation thread 11, the second buffer allocation thread 22, and the third buffer allocation thread 32 enter the runnable state multiple times, it may cause the first buffer allocation thread 12 to not complete the allocation of buffer 100 until time t16.

[0085] In this scenario, rendering thread 11 remains in a state of waiting to retrieve buffer 100 from time t13 to t16. (Comparison) Figure 2a Clearly, the rendering thread 11 of the first application waited too long to fetch buffer 100 between time t13 and time t16.

[0086] However, if the explicit method provided in this application is used, multiple buffer allocation threads can allocate buffers in parallel in scenarios where the buffer allocation thread may enter a non-running state. For example, Figure 2d It shows Figure 2c The diagram shows the execution timing after using the display method provided in this application in the scenario shown.

[0087] For example, see Figure 2d The main thread 10 of the first application starts initialization at time t11. At this time, since the interface for allocating buffers can be called in parallel based on the display method provided by this application, the rendering thread 11 can request buffer 100 from the allocation service at time t11. The first buffer allocation thread 12 created by the allocation service can start allocating buffer 100 for the rendering thread 11 at time t11.

[0088] like Figure 2d As shown, from time t10 to t15', the first allocation buffer thread 12, the second allocation buffer thread 22, and the third allocation buffer thread 32 created by the allocation service can allocate buffers 100, 200, and 300 in parallel for the rendering threads 11, 12, and 13 of the first application, respectively. Rendering threads 12 and 13 are not shown here. Therefore, even if the first allocation buffer thread 12 enters the runnable state multiple times, the allocation of buffer 100 can be completed at time t14'. Compared to... Figure 2cThe scenario shown can effectively shorten the time that rendering thread 11 waits to retrieve buffer 100.

[0089] In this scenario, based on the drawing command issued by the main thread 10 of the first application at time t12, the rendering thread 11 can begin fetching buffer 100 at time t13 upon receiving the drawing command, and will have fetched buffer 100 by time t14' after the first buffer allocation thread 12 has completed allocating buffer 100, thus enabling drawing operations to begin at time t14'. It can be understood that the rendering thread 11 waits only from time t13 to time t14' to fetch buffer 100. (Compared to the aforementioned...) Figure 2b During the time intervals t13 to t16, the rendering thread 11 waits to retrieve the buffer 100. Clearly, the waiting time for the rendering thread 11 to retrieve the buffer 100 is significantly shortened in the display method of this application. Therefore, it avoids display stuttering and frame skipping caused by the application's rendering thread entering a runnable state and thus waiting too long for the buffer to be retrieved.

[0090] Furthermore, based on the aforementioned Figure 2a The diagram shown illustrates the serial allocation of buffers by the allocation thread. Figure 2e This diagram illustrates the execution timing of serial buffer allocation when the buffer allocation thread may enter an uninterruptible sleep state (D state).

[0091] For example, in some scenarios, if the node that the allocation buffer threads corresponding to the first application, the second application, and the third application need to access is occupied by other threads or modules, causing the allocation buffer threads to be unable to access the node, the allocation buffer threads that cannot access the node may all enter state D.

[0092] It is understandable that each buffer allocation thread can only request a buffer for its corresponding rendering thread when it is not in a D state, where a non-D state could be a running state, etc. Therefore, the time required for each buffer allocation thread to request a buffer may increase due to entering the D state.

[0093] For example, see Figure 2eThe second buffer allocation thread 22 and the third buffer allocation thread 32 may enter the D state multiple times, resulting in the first buffer allocation thread 11 not completing the allocation of buffer 200 and buffer 300 sequentially until time t25. Similarly, the first buffer allocation thread 11 may also enter the D state multiple times, increasing the time required to allocate buffer 100. For example, if the first buffer allocation thread 11, the second buffer allocation thread 22, and the third buffer allocation thread 32 enter the D state multiple times, the first buffer allocation thread 12 may not complete the allocation of buffer 100 until time t26.

[0094] In this scenario, rendering thread 11 is in a state of waiting to request a buffer from time t23 to time t26. Figure 2a Clearly, the rendering thread 11 of the first application waited too long for the wait time to fetch buffer 100 from time t23 to t26.

[0095] However, if the explicit method provided in this application is used, multiple buffer allocation threads can allocate buffers in parallel in scenarios where the buffer allocation thread may enter the D state. For example, Figure 2f It shows Figure 2e The diagram shows the execution timing after using the display method provided in this application in the scenario shown.

[0096] For example, in a scenario where the thread allocating the buffer might enter state D, Figure 2f The diagram illustrates the timing of the simultaneous allocation of buffers by the rendering threads of the first, second, and third applications in an electronic device based on the display method provided in this application.

[0097] For example, see Figure 2f The main thread 10 of the first application begins initialization at time t21, causing the rendering thread 11 of the first application to request buffer 100 from the allocation service at time t21. Based on the display method provided in this application, the first buffer allocation thread 12 can begin allocating buffer 100 for the rendering thread 11 at time t21.

[0098] like Figure 2f As shown, from time t20 to t25', the first buffer allocation thread 12, the second buffer allocation thread 22, and the third buffer allocation thread 32 can allocate buffers 100, 200, and 300 in parallel for rendering threads 11, 12, and 13, respectively. Rendering threads 12 and 13 are not shown here. Therefore, even if the first buffer allocation thread 12 enters state D multiple times, it can still complete the allocation of buffer 100 by time t26'.

[0099] In this case, based on the drawing instruction issued by the main thread 10 of the first application at time t22, the rendering thread 11 can start extracting the buffer 100 at time t23 after receiving the drawing instruction, and extract the buffer 100 at time t26' after the first buffer allocation thread 12 completes the allocation of the buffer 100, so as to start the drawing operation at time t26'.

[0100] It is understandable that the time during which rendering thread 11 waits to fetch buffer 100 is only from time t23 to time t26'. (Compared to the aforementioned...) Figure 2c During the time intervals from t23 to t26, the rendering thread 11 waits to retrieve the buffer 100. Clearly, the waiting time for the rendering thread 11 to retrieve the buffer 100 is significantly shortened in the display method of this application. Therefore, it avoids display stuttering and frame skipping caused by the application's rendering thread entering state D and waiting for the buffer to be retrieved for too long.

[0101] In some embodiments, the aforementioned lock that restricts an interface to serial access only can be used to protect global variables within that interface from concurrent read and write operations. Therefore, the explicit method provided in this application, by removing the lock corresponding to the interface used for allocating buffers in the allocation service that restricts the interface to serial access only, or by adjusting the scope of the lock, can also set the global variable protected by the lock as a local variable to prevent concurrent read and write operations on that variable. For example, for Android... TM The `dma_legacy_dev_fd_` variable in the AllocBuffer interface of the system, which is prohibited from concurrent read / write operations, can be modified to a local variable type. This ensures that each thread calling the interface to allocate buffers has a corresponding `dma_legacy_dev_fd` value, and modifications to this variable by different threads do not affect each other. In this way, while enabling parallel buffer allocation by allocation threads, exceptions to the interface calls caused by concurrent read / write operations on the `dma_legacy_dev_fd` variable can be avoided.

[0102] In some embodiments, global variables that are prohibited from concurrent read / write operations may need to have their values ​​cleared during destruction. Therefore, the explicit method provided in this application can also set a global scope set and store the values ​​of all global variables in this set. Furthermore, when destroying the allocation buffer thread that accesses the interface, all values ​​of the global variable can be cleared based on this set. For example, a global set can be created to store all values ​​of the variable `dma_legacy_dev_fd_`. This further avoids destruction exceptions in the allocation buffer thread.

[0103] The display method provided in this application will now be described in detail with reference to the accompanying drawings.

[0104] Specifically, Figure 3 An embodiment of this application illustrates a flowchart of how an allocation service allocates buffers for the rendering threads of multiple applications based on the display method provided in this application.

[0105] Understandable. Figure 3 The execution entity for each step of the process shown can be the allocation service in electronic device 1A. For ease of description, the execution entity for each step will not be described again below.

[0106] It should also be stated that the steps in the methods and processes in this application are numbered for ease of reference, not to limit the order of steps. If there is an order between the steps, the textual description shall prevail.

[0107] Specifically, the display method provided in this application embodiment may include the following steps:

[0108] 301: Receives buffer requests from multiple rendering threads.

[0109] For example, the allocation service may receive multiple buffer requests from rendering threads within a certain time period, which may require allocating buffers for rendering threads of multiple applications simultaneously.

[0110] Here, multiple rendering threads that send buffer request requests to the allocation service within a certain time period can be rendering threads corresponding to different applications. No restrictions are imposed on the rendering threads that send buffer request requests to the allocation service.

[0111] For example, the multiple rendering threads that send buffer requests to the allocation service can be as described above. Figure 2a and Figure 2b The rendering threads are 11 for the first application, 21 for the second application, and 31 for the third application. No restrictive statement is made regarding the timing of buffer allocation requests sent by the rendering threads of multiple applications. It can be understood that multiple application rendering threads can send requests to the allocation service at the same time or at different times within a certain time period. The aforementioned simultaneous allocation of buffers for multiple application rendering threads can be understood as an overlap in the timing of the allocation service's process for allocating buffers for multiple application rendering threads.

[0112] 302: Creates a corresponding buffer allocation thread for each rendering thread that sends a request for a buffer.

[0113] For example, based on the aforementioned step 301, after receiving the request for a buffer from each rendering thread, the allocation service can create a corresponding allocation buffer thread for each rendering thread.

[0114] For example, see Figure 2a and Figure 2b The allocation service can create a first allocation buffer thread 12 for the rendering thread 11 of the first application, a second allocation buffer thread 22 for the rendering thread 21 of the second application, and a third allocation buffer thread 32 for the rendering thread 31 of the third application.

[0115] In one example, each time the allocation service receives a buffer request from a rendering thread, it can create a corresponding allocation buffer thread to perform the process of allocating a buffer for that rendering thread.

[0116] Specifically, the application's rendering thread can request a buffer from the allocation service, causing the allocation service to create an allocation buffer thread for the application to allocate the buffer.

[0117] Furthermore, to achieve buffer recycling, the application's rendering thread may request multiple buffers from the allocation service based on a buffer rotation mechanism. In this case, if the allocation service receives multiple buffer requests from a rendering thread within a certain period, it can either create an allocation thread for that rendering thread to allocate the aforementioned multiple buffers, or create multiple allocation threads for that rendering thread to allocate the aforementioned multiple buffers in parallel. The specific process and implementation of the allocation service creating allocation threads are not described restrictively here.

[0118] Specifically, in one example scenario, the rendering thread of a desktop application may request one or more buffers from the allocation service to draw the desktop interface; the rendering thread of a negative one screen application may request one or more buffers from the allocation service to draw the negative one screen interface. Furthermore, the allocation service may create one or more allocation buffer threads for the desktop application in response to a buffer request sent by the rendering thread of the negative one screen application, and may create one or more allocation buffer threads for the negative one screen application in response to a buffer request sent by the rendering thread of the negative one screen application.

[0119] 303: Based on the establishment of multiple allocation buffer threads, the rendering thread corresponding to each allocation buffer thread allocates buffers in parallel.

[0120] For example, see Figure 2a and Figure 2bThe allocation service can allocate buffer 100 for the rendering thread 11 of the first application based on the first allocation buffer thread 12, allocate buffer 200 for the rendering thread 21 of the second application based on the second allocation buffer thread 22, and allocate buffer 300 for the rendering thread 31 of the third application based on the third allocation buffer thread 32.

[0121] In some embodiments, after each buffer allocation thread has preempted processor resources, it can call the interface for allocating buffers to allocate buffers for its corresponding rendering thread. That is, at the same time, multiple buffer allocation threads can call the interface for allocating buffers to allocate buffers for their respective rendering threads.

[0122] For example, the distribution service in electronic device 1A is Android. TM Taking the vendor.qti.hardware.display.allocator-service in the system as an example, this application provides a detailed explanation of the specific implementation of the display method that enables the allocation service to allocate buffers in parallel.

[0123] Here, the AllocBuffer interface in vendor.qti.hardware.display.allocator-service is within the scope of buffer_lock, which is a lock to prevent concurrent reads and writes of the dma_legacy_dev_fd variable in the AllocBuffer interface. It can be understood that because the AllocBuffer interface is within the scope of buffer_lock, it can only be called serially by the buffer allocation threads; that is, one buffer allocation thread can only call the AllocBuffer interface after another has completed allocating the buffer. Therefore, by setting the AllocBuffer interface outside the scope of buffer_lock, it can be called concurrently by multiple buffer allocation threads.

[0124] It is understood that the allocation service in this application can also be other services capable of allocating buffers for applications. This application does not impose any restrictive description on the specific type of allocation service. For allocation services other than vendor.qti.hardware.display.allocator-service, if the interface used for allocating buffers in that allocation service is also protected by a lock that restricts access to serial access only, then that interface can also be set outside the scope of that lock.

[0125] Furthermore, if there are no variables in the interface that are prohibited from being read or written concurrently, the lock can be directly deleted. It can be understood that by deleting the lock that restricts the interface to serial access, the interface used for allocating buffers can also be called in parallel.

[0126] Furthermore, continuing with the example of `vendor.qti.hardware.display.allocator-service`, since the `dma_legacy_dev_fd` variable in the interface is prohibited from concurrent read and write, after setting the `AllocBuffer` interface outside the scope of `buffer_lock`, to prevent concurrent read and write operations on the `dma_legacy_dev_fd` variable, it can be set as a local variable. It can be understood that for a local variable type `dma_legacy_dev_fd`, each thread and / or module calling the `AllocBuffer` interface has a corresponding `dma_legacy_dev_fd` value, and modifications to this variable value by different threads and / or modules will not affect each other. Therefore, concurrent read and write operations on the `dma_legacy_dev_fd` variable, which is located outside the scope of `buffer_lock`, can be effectively avoided.

[0127] It can be understood here that threads and / or modules that call the AllocBuffer interface include, but are not limited to, the aforementioned buffer allocation thread.

[0128] Furthermore, since each thread and / or module calling the AllocBuffer interface needs to clear the dma_legacy_dev_fd variable value during destruction, for example, the thread allocating the buffer needs to clear the dma_legacy_dev_fd variable value after completing the buffer allocation. Therefore, after setting the dma_legacy_dev_fd variable to a local variable type, a globally scoped collection can be set in the AllocBuffer interface. For example, a set collection can be set in the AllocBuffer interface to store all dma_legacy_dev_fd variable values. Then, when the thread and / or module calling the AllocBuffer interface is destroyed, the dma_legacy_dev_fd variable value can be globally cleared by clearing this collection.

[0129] Below, based on the specific process of the allocation service allocating buffers in parallel for multiple applications, taking the allocation service allocating buffers in parallel for the first application, the second application, and the third application as examples, the interaction process between each application and the allocation service will be explained in detail.

[0130] For example, Figure 4 Taking the allocation of service buffers for the rendering threads of the first, second, and third applications as an example, an interactive diagram is shown.

[0131] It is understood that the first application, the second application, and the third application can be third-party applications or system applications. This application does not impose any restrictive description on the types of the first application, the second application, and the third application.

[0132] Here, the first application may include a main thread 10 and a rendering thread 11 (not shown in the figure). The rendering thread 11 may include rendering thread 110 and rendering thread 111. The main thread 10 may perform initialization operations during initial execution, or when switching from background to foreground execution. After initialization, the main thread 10 may send drawing commands to the rendering thread 11. The rendering thread 111 within the rendering thread 11 may request a buffer 100 from the allocation service based on the initialization operation of the main thread 10. This allows the allocation service to create a first allocation buffer thread 12 corresponding to the first application, and allocate the buffer 100 to the rendering thread 11 through this first allocation buffer thread 12. Upon receiving the drawing commands sent by the main thread 10, the rendering thread 110 within the rendering thread 11 may extract the buffer 100 allocated by the allocation service and perform drawing operations within the extracted buffer 100.

[0133] Correspondingly, the second application may include a main thread 20 and a rendering thread 21, whereby the rendering thread 21 may include rendering threads 210 and 211. The third application may include a main thread 30 and a rendering thread 31, whereby the rendering thread 31 may include rendering threads 310 and 311. Here, Figure 4 Only rendering thread 211 and rendering thread 311 of the second application are shown in the image.

[0134] It is understandable that the operations performed by main threads 20 and 30 are essentially the same as those performed by main thread 10; the operations performed by rendering threads 210 and 310 are essentially the same as those performed by rendering thread 110; and the operations performed by rendering threads 211 and 311 are essentially the same as those performed by rendering thread 111. Further details will not be elaborated upon here.

[0135] Furthermore, it is understandable. Figure 4This example only illustrates how the first, second, and third applications each request one buffer from the allocation service. It can be understood that to achieve cyclical use of buffers, each application could request multiple buffers from the allocation service based on a buffer rotation mechanism. No restrictions are placed on the number of buffers requested by each application from the allocation service. For example, an application could request three or four buffers from the allocation service based on its rendering thread. The process of an application's rendering thread requesting multiple buffers from the allocation service can be performed serially or in parallel; no restrictions are placed on the specific implementation methods for each application requesting multiple buffers.

[0136] Specifically, Figure 4 The illustrated allocation service and its interaction flow for allocating buffers to multiple applications may include the following steps:

[0137] 400: The rendering thread 211 of the second application sends a request for a buffer to the allocation service.

[0138] For example, based on the initialization operation that the main thread 20 of the second application starts at time t40, the rendering thread 211 of the second application starts requesting buffer 200 from the allocation service at time t40.

[0139] It is understandable that the second application may have run for the first time at time t40, or switched from running in the background to running in the foreground at time t40, thus causing the main thread 20 to start the initialization operation at time t40.

[0140] Furthermore, if the content of the display interface and / or the size of the display window required by the second application at time t40 changes significantly, the rendering thread 211 of the second application may begin requesting buffer 200 from the allocation service at time t40. Here, we will not provide restrictive descriptions of the specific scenarios in which the rendering thread 211 requests buffers from the allocation service.

[0141] Here, the initialization process of the main thread 20 of the second application, which begins at time t40, is... Figure 4 The initialization process of the main thread 10 of the first application corresponding to step 404 at time t42 is essentially the same, therefore, Figure 4 The initialization process of the main thread 20 at time t40 is not shown.

[0142] 401: The allocation service creates a second allocation buffer thread 22.

[0143] For example, after receiving a request for a buffer from the rendering thread 211 of the second application at time t40, the allocation service can create a second allocation buffer thread 22 corresponding to the rendering thread 211.

[0144] 402: Second allocation buffer thread 22 allocates buffer 200.

[0145] For example, after the second buffer allocation thread 22 is established, it can start allocating buffer 200 for the rendering thread 211 of the second application at time t40, and complete the allocation of buffer 200 at time t45.

[0146] Furthermore, the second buffer allocation thread 22 completed the allocation of buffer 200 by time t45. Here, the time taken by the second buffer allocation thread 22 to allocate buffer 200 is the duration from time t40 to time t45. This time may be affected by the second buffer allocation thread 22 entering the runnable state and / or the D state multiple times. The reasons why the buffer allocation thread 22 may enter the runnable state or the D state are as described above and will not be repeated here.

[0147] It is understandable that since the second allocation buffer thread 22 completed the allocation of buffer 200 at time t45, the rendering thread 211 of the second application can also send a request to the allocation service at time t45.

[0148] 403: The rendering thread 311 of the third application sends a request for a buffer to the allocation service.

[0149] For example, based on the initialization operation started by the main thread 30 of the third application at time t41, the rendering thread 311 of the third application starts to request the buffer 300 from the allocation service at time t41.

[0150] Here, the initialization process of the main thread 30 of the third application, which begins at time t41, is... Figure 4 The initialization process of the main thread 10 of the first application corresponding to step 404 at time t42 is essentially the same. Figure 4 This process is not shown in the diagram and will not be described in detail here.

[0151] Furthermore, the specific scenario where rendering thread 311 starts requesting buffer 300 from the allocation service at time t41 can be found in the detailed description of step 400 above, and will not be repeated here.

[0152] 404: The allocation service created a third allocation buffer thread 32.

[0153] For example, when the allocation service receives a request for a buffer from the rendering thread 311 of a third application at time t41, the allocation service may create a third allocation buffer thread 32.

[0154] 405: Third allocation buffer thread 32 allocates buffer 300.

[0155] For example, after the third buffer allocation thread 32 is established, it can start allocating buffer 300 for the rendering thread 311 of the third application at time t41 and complete the allocation at time t46.

[0156] Here, although the allocation service is still allocating buffer 200 for the second application based on the second allocation buffer thread 22 at time t41, the allocation service is based on the aforementioned Figure 3 The illustrated process of allocating buffers in parallel for multiple applications allows for the simultaneous allocation of buffer 300 to a third application based on the third buffer allocation thread 32 at time t41. That is, starting from time t41, the allocation service simultaneously allocates buffers for both the second and third applications.

[0157] Furthermore, the third buffer allocation thread 32 completed the allocation of buffer 300 by time t46. Here, the time taken by the second buffer allocation thread 32 to allocate buffer 300 is the duration from time t41 to time t46. This time may be affected by the first buffer allocation thread 32 entering the runnable state and / or the D state multiple times. The reasons why the buffer allocation thread 32 may enter the runnable state or the D state are as described above and will not be repeated here.

[0158] It is understandable that since the third allocation buffer thread 32 completed the allocation of buffer 300 at time t46, the rendering thread 311 of the third application can also send a request to the allocation service at the end of time t46.

[0159] 406: The main thread 10 of the first application is initialized.

[0160] For example, the main thread 10 of the first application can begin initialization operations at time t42. The scenario where the main thread 10 begins initialization operations at time t42 can be found in the detailed description of step 400 above, and will not be repeated here.

[0161] 407: The rendering thread 111 of the first application sends a request for a buffer to the allocation service.

[0162] For example, based on the initialization operation performed by the main thread 10 of the first application at time t42, the rendering thread 111 of the first application may request the buffer 100 from the allocation service at time t42.

[0163] Here, the scenario where the rendering thread 111 of the first application starts requesting buffer 100 from the allocation service at time t42 can be found in the relevant description in step 400 above, and will not be repeated here.

[0164] 408: The allocation service creates the first allocation buffer thread 12.

[0165] For example, after receiving a request for a buffer from the rendering thread 111 of the first application at time t42, the allocation service can create a first allocation buffer thread 12 corresponding to the rendering thread 111.

[0166] 409: First allocation buffer thread 12 allocates buffer 100.

[0167] For example, after the first buffer allocation thread 12 is established, it can start allocating buffer 100 for the rendering thread 111 of the first application at time t42 and complete the allocation at time t47.

[0168] Here, although the allocation service is still allocating buffer 200 for the second application based on the second allocation buffer thread 22 and allocating buffer 300 for the third application based on the third allocation buffer thread 32 at time t42, the allocation service is based on the aforementioned Figure 3 The illustrated process of allocating buffers in parallel for multiple applications allows for the simultaneous allocation of buffer 100 to the first application based on the first buffer allocation thread 12 at time t42. That is, starting from time t42, the allocation service simultaneously allocates buffers for the first application, the second application, and the third application.

[0169] Furthermore, the first buffer allocation thread 12 completed the allocation of buffer 100 by time t47. Here, the time taken by the first buffer allocation thread 12 to allocate buffer 100 is the duration from time t42 to time t47. This time may be affected by the first buffer allocation thread 12 entering the runnable state and / or the D state multiple times. The reasons why the first buffer allocation thread 12 may enter the runnable state or the D state are as described above and will not be repeated here.

[0170] It is understandable that since the first allocation buffer thread 12 completed the allocation of buffer 100 at time t47, the rendering thread 111 of the first application can also send a request to the allocation service at time t47.

[0171] 410: The main thread 10 of the first application sends drawing instructions to the rendering thread 110.

[0172] For example, after the main thread 10 of the first application completes initialization, it can send drawing instructions to the rendering thread 110 at time t43.

[0173] 411: The rendering thread 110 of the first application extracts the data into buffer 100.

[0174] For example, when the rendering thread 110 of the first application receives the drawing instruction sent by the main thread 10 at time t44, it can start requesting the allocation service to extract the buffer 100 at time t44 and extract the buffer 100 at time t47.

[0175] It is understandable that, since the first buffer allocation thread 12 has not yet completed the allocation of buffer 100 at time t44, the rendering thread 110 will enter a state of waiting to retrieve buffer 100. For example, the rendering thread 110 is in a state of waiting to retrieve buffer 100 from time t44 to time t47. That is, from time t44 to time t47, the rendering thread 110 receives the drawing instructions from the main thread, but cannot draw the display interface based on buffer 100. Until time t47, the first buffer allocation thread 12 completes the allocation of buffer 100. At this time, the rendering thread retrieves buffer 100, and then, based on the following step 409, the interface content to be displayed can be drawn in buffer 100.

[0176] Here, it can be understood that, in comparison with the aforementioned Figures 2a to 2c The scheme shown illustrates a serial allocation service that allocates buffers for multiple applications. Taking the process of the first application displaying its interface as an example, Figure 4 The parallel scheme shown will greatly shorten the time required for the rendering thread 110 of the first application to wait to retrieve the buffer 100. Since the time interval between the rendering thread 110 receiving the drawing command and retrieving the buffer 100 is greatly shortened, it can effectively avoid the first application being unable to display the application interface due to the inability to obtain the buffer 100 for drawing the interface content for a long time, thus avoiding stuttering and frame drops during the interface display process.

[0177] Furthermore, it is understood that for the second and third applications, the display method provided in this application also shortens the time required for rendering thread 210 and rendering thread 310 to wait to retrieve buffer 200 and buffer 300.

[0178] 412: The rendering thread 110 of the first application performs the drawing.

[0179] For example, the rendering thread 110 of the first application can draw and render the display content corresponding to the first application after retrieving the buffer 100.

[0180] Specifically, when the first allocation buffer thread 12 completes the allocation of buffer 100 at time t47, the rendering thread 110 of the first application retrieves buffer 100 at time t47. Then, the interface content to be displayed can be drawn in buffer 100 starting at time t47 to realize the display of the interface of the first application.

[0181] It is understood that when the second allocation buffer thread 22 completes the allocation of buffer 200 at time t45, the rendering thread 210 of the second application (not shown in the figure) retrieves buffer 200 at time t45. Then, the interface content to be displayed can be drawn in buffer 200 starting at time t45 to realize the display of the interface of the second application.

[0182] It is understandable that when the third allocation buffer thread 32 completes the allocation of buffer 300 at time t46, the rendering thread 310 of the third application (not shown in the figure) retrieves buffer 300 at time t46. Then, the interface content to be displayed can be drawn in buffer 300 starting at time t46 to realize the display of the interface of the third application.

[0183] Specifically, in one exemplary scenario, see the foregoing Figure 1 As shown, electronic device 1A may display the chat interface of an instant messaging application in full screen. When the user of electronic device 1A switches the chat interface to a multitasking interface by swiping up on the screen, the window size of the chat interface changes significantly. Therefore, the rendering thread of the instant messaging application may request a buffer from the allocation service. Simultaneously, the desktop application used to display the multitasking interface switches from background to foreground. At this time, the rendering thread of the desktop application may request a buffer from the allocation service based on the initialization of the desktop application's main thread. Furthermore, since the use of the application on the negative one screen is highly correlated with that of the desktop application, most electronic device manufacturers initialize the display strategy of the application on the negative one screen when the desktop application initializes. Therefore, in Figure 1 In the scenario shown, the rendering thread of the application on the negative one screen may also request a buffer from the allocation service.

[0184] Furthermore, desktop applications, negative one screen applications, and instant messaging applications may simultaneously request buffers from the allocation service. Consequently, the allocation service for electronic device 1A can be based on the aforementioned... Figure 3 and Figure 4 The essentially the same process involves allocating buffers in parallel for desktop applications, the negative one screen application, and instant messaging applications. This reduces the time required for the rendering threads of these applications to wait for buffer retrieval. This avoids stuttering and frame drops when the user swipes up from the chat interface to the multitasking interface.

[0185] Here, the process by which the allocation service of electronic device 1A allocates buffers in parallel for desktop applications, negative one screen applications, and instant messaging applications can be found in the aforementioned section. Figure 3 and Figure 4 The specific details will not be elaborated here.

[0186] In addition, when a user of electronic device 1A switches the chat interface to a multitasking interface by swiping up on the display screen, the applications corresponding to other application interfaces displayed in the multitasking interface may also request a buffer from the allocation service.

[0187] For example, see Figure 5 The diagram illustrates a multitasking interface 500, which includes a chat interface 501 for an instant messaging application, a messaging interface 502 for an SMS application, a memo interface 503 for a memo application, and a calculation interface 504 for a calculator application. Here, one or more of the rendering threads corresponding to the instant messaging application, SMS application, memo application, and calculator application may request a buffer from the allocation service to display their respective interface content. It is understood that the multitasking interface may also display a playback interface for a video application, etc. Therefore, no limiting description is made regarding the interface content displayed in the multitasking interface.

[0188] Figure 6 A schematic diagram of the structure of electronic device 1A is shown.

[0189] Electronic device 1A may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0190] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 1A. In other embodiments of this application, the electronic device 1A may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0191] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0192] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0193] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the aforementioned memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0194] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0195] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the electronic device 1A.

[0196] Electronic device 1A implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0197] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Mini-LED, a Micro-LED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 1A may include one or N displays 194, where N is a positive integer greater than 1.

[0198] Internal memory 121 can be used to store computer executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 1A (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of electronic device 1A by running instructions stored in internal memory 121 and / or instructions stored in memory located within the processor.

[0199] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 1A, in a different position than display screen 194.

[0200] Figure 7 This is a software structure block diagram of electronic device 1A according to an embodiment of the present invention.

[0201] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TM The system is divided into five layers, from top to bottom: application layer, application framework layer, Android layer, and so on. TM runtime (Android) TM The runtime, hardware abstraction layer (HAL), system libraries, and kernel layer.

[0202] The application layer can include a series of application packages.

[0203] like Figure 7 As shown, the application package may include the aforementioned first application, second application, third application, desktop application, and other applications. The desktop application may include the aforementioned desktop process for displaying the desktop interface and the aforementioned negative one screen process for displaying the negative one screen.

[0204] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0205] like Figure 7 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0206] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0207] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, etc.

[0208] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0209] The phone manager is used to provide communication functions for electronic devices (I / A). For example, it manages call status (including connection and disconnection).

[0210] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0211] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting alert sounds, causing electronic devices to vibrate, or flashing indicator lights.

[0212] Android TM Runtime includes core libraries and a virtual machine. Android TM The runtime is responsible for scheduling and management of the Android system.

[0213] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0214] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0215] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0216] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0217] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0218] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0219] A 2D graphics engine is a graphics engine for 2D drawing.

[0220] The Hardware Abstraction Layer (HAL) is an interface layer located between the kernel layer and the hardware circuitry. Its purpose is to abstract the hardware. It hides the hardware interface details of a specific platform, providing the operating system with a virtual hardware platform that is hardware independent and portable across multiple platforms.

[0221] The hardware abstraction layer can include the aforementioned allocation service. When the rendering thread of an application in the application layer needs to allocate a buffer, it can do so cross-process based on the allocation service. Here, the allocation service could be Android... TM The system's vendor.qti.hardware.display.allocator-service. Furthermore, this allocation service can include an interface for requesting buffers; for example, this interface could be the AllocBuffer interface within vendor.qti.hardware.display.allocator-service.

[0222] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0223] This application also provides a computer program product for implementing the display methods provided in the above embodiments.

[0224] Various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or combinations of these implementation methods. Embodiments of this application can be implemented as computer program modules or module code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0225] Computer program modules or module code can be applied to input instructions to perform the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0226] Module code can be implemented using a high-level modular language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used to implement module code when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0227] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagated signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0228] The disclosure of embodiments of this application also relates to a computer program product for performing operations in a text, the computer program product comprising: computer program code that, when run on a computer, causes the computer to perform the operations performed by electronic device 1A in any of the embodiments of the specification.

[0229] In this specification, the reference to "an embodiment" or "an embodiment" means that a specific feature, structure, or characteristic described in connection with the embodiment is included in at least one exemplary implementation or technology disclosed according to an embodiment of this application. The appearance of the phrase "in an embodiment" in various places in the specification does not necessarily refer to the same embodiment.

[0230] The disclosure of embodiments of this application also relates to means for performing operations in text. This means may be specifically constructed for the claimed purpose or may include a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored on a computer-readable medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, application-specific integrated circuits (ASICs), or any type of medium suitable for storing electronic instructions, and each may be coupled to a computer system bus. Furthermore, the computer mentioned in the specification may include a single processor or may employ an architecture involving multiple processors for increased computing power.

[0231] Furthermore, the language used in this specification has been primarily chosen for readability and instructional purposes and may not have been chosen to depict or limit the disclosed subject matter. Therefore, the embodiments disclosed herein are intended to illustrate, and not limit, the scope of the concepts discussed herein.

Claims

1. A display method applied to an electronic device, characterized in that, The method includes: A first instruction to display the first application interface was detected; Allocate a first buffer for the first rendering thread of the first application interface, and render the first application interface based on the first buffer; A switching instruction is detected to switch the first application interface to display M second application interfaces, where M is greater than or equal to 2. Multiple second buffers are allocated in parallel to N second rendering threads corresponding to the M second application interfaces, and the multiple second application interfaces are rendered based on the multiple second buffers, wherein M is less than or equal to N; The method of allocating multiple second buffers in parallel for the N second rendering threads corresponding to the M second application interfaces includes: Upon receiving the requests for buffers from the N second rendering threads, create corresponding allocation threads for each of the N second rendering threads; Buffers are allocated in parallel for the N second rendering threads based on N allocation threads; The electronic device includes a first service for allocating a buffer, the first service including a first interface, and... The method of allocating buffers in parallel for the N second rendering threads based on N allocation threads includes: The first allocation thread among the N allocation threads calls the first service to allocate a buffer for the second rendering thread corresponding to the first allocation thread during the first allocation period. The second allocation thread among the N allocation threads calls the first service to allocate a buffer for the second rendering thread corresponding to the second allocation thread during the second allocation period; wherein the first allocation period and the second allocation period overlap or partially overlap. The first service also includes a first lock, wherein the scope of the first lock does not include the first interface, and the first lock is used to prevent the first variable in the first service from being read and written concurrently.

2. The method according to claim 1, characterized in that, M is 2, and the first application interface and the second application interface U2 among the M second application interfaces are the interfaces of the first application; and, The M second application interfaces also include the second application interface U3 of the second application.

3. The method according to claim 2, characterized in that, The switching instruction is used to instruct any of the following: The second application interface U2 and the second application interface U3 are displayed in a split-screen format; The second application interface U2 is displayed in full screen, and the second application interface U3 is displayed in a floating window; The second application interface U3 is displayed in full screen, and the second application interface U2 is displayed in a floating window.

4. The method according to claim 1, characterized in that, The switching command is used to instruct the display of a multitasking interface on the desktop. The multitasking interface includes the M second application interfaces, where M is less than N, and... The N second rendering threads include M second rendering threads corresponding to the second application interfaces of the M second applications, and second rendering threads corresponding to desktop applications.

5. The method according to claim 4, characterized in that, The second rendering thread corresponding to the desktop application includes: the second rendering thread corresponding to the multitasking interface; or... The second rendering thread corresponding to the multitasking interface and the second rendering thread corresponding to the negative one screen interface.

6. The method according to claim 4, characterized in that, The detection of the switching instruction to switch the display of the first application interface to the display of M second application interfaces includes: The switching command is detected when the user swipes up from the bottom of the screen of the electronic device.

7. The method according to any one of claims 1 to 5, characterized in that, The first allocation period overlaps or partially overlaps with the second allocation period, including any one of the following: The start time of the first allocation period is the same as the start time of the second allocation period and / or the end time of the first allocation period is the same as the end time of the second allocation period. The start time of the first allocation period is between the start time and the end time of the second allocation period; The end time of the first allocation period is located between the start time and the end time of the second allocation period.

8. An electronic device, characterized in that, include: One or more processors; One or more memories; the one or more memories storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the display method according to any one of claims 1 to 7.

9. A computer-readable medium, characterized in that, The readable medium stores instructions that, when executed on a computer, cause the computer to perform the display method according to any one of claims 1 to 7.

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

Images