Display method, electronic equipment and computer readable medium

Abstract

The invention relates to the technical field of computers, in particular to a display method, electronic equipment and a computer readable medium. Under the condition that the distribution service receives buffer area application requests sent by a plurality of rendering threads, buffer areas can be applied for all the rendering threads. The distribution service can start to distribute a buffer area for another rendering thread before distributing the buffer area for one rendering thread. Therefore, in the process that the distribution service distributes the buffer areas for the plurality of rendering threads, the buffer area does not need to be applied for the next rendering thread after the buffer area corresponding to one rendering thread is applied for. Based on the method, the time required by each rendering thread to wait for extracting the buffer area can be shortened, the conditions of display interface jamming and frame skipping caused by too long waiting time are avoided, the fluency of the display interface is improved, and the user experience is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a display method, an electronic device and a computer-readable medium. Background Art

[0002] In the scenario of generating the application interface of an application, the rendering thread corresponding to the application first applies to the allocator service for a buffer for drawing and rendering the application interface content. Then, the rendering thread draws and renders the application interface into the requested buffer. Secondly, the process used to synthesize the display interface in the electronic device (for example, SurfaceFlinger) can synthesize 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 the foreground and the background, or when the window size of the application interface and / or the amount of data to be displayed changes, the rendering thread of the application needs to reapply to the allocation service for a buffer for drawing and rendering the interface content. If multiple applications of an electronic device apply for buffers from the allocation service, the allocation service will allocate buffers for the application interfaces of each application in series. That is, after allocating a buffer for one application interface, a buffer is allocated for the next application. Doing so will cause the application with a later application order among the multiple applications to wait longer for the buffer, which will increase the time it takes for the application to draw and render the interface, and further cause freezes or frame drops in the display process of its application interface.

[0004] For example, see Figure 1 , the screen of the mobile phone 10A displays the chat interface 100a of the instant messaging application. During the process of the user sliding up the screen of the mobile phone 10A, the mobile phone 10A gradually switches from displaying the chat interface 100a to displaying the multitasking interface 100b. It can be understood that the interface switching process can be displayed by the desktop application process.

[0005] When the user slides up the screen, the window size of the chat interface 100a of the instant messaging application changes, and the desktop application switches from background operation to foreground operation. Therefore, both the instant messaging application and the desktop application will reapply for the buffer from the allocation service of the mobile phone 100. If the allocation service allocates a buffer to the desktop application first, it may cause a delay in drawing the chat interface 100a of the instant messaging application, resulting in a freeze in the process of the chat interface 100a window gradually becoming smaller; if the allocation service allocates a buffer to the instant messaging application first, it may cause a delay in drawing the multitasking interface 100b, resulting in a freeze in the desktop application when switching from the chat interface 100a to the multitasking interface 100b. Summary of the invention

[0006] The present application provides a display method, an electronic device, and a computer-readable medium, which can avoid freezes, frame drops, and the like when an electronic device displays multiple application interfaces simultaneously.

[0007] In a first aspect, the present application provides a display method for an electronic device, the display method comprising: detecting a first instruction to display a first application interface; allocating a first buffer to 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; allocating multiple second buffers in parallel to N second rendering threads corresponding to the M second application interfaces, and rendering multiple second application interfaces respectively based on the multiple second buffers, wherein M is less than or equal to N.

[0008] Here, the first application interface may be a display interface of a first application program, and the first instruction for displaying the first application interface may be any system instruction and / or user operation that enables the first application program to display the first application interface. Here, no restrictive description is given to the first instruction. Exemplarily, the first rendering thread may be a rendering thread of the first application program, and the first rendering thread may be used to render and draw the first application interface. The M second application interfaces may be application interfaces of one or more applications. It can be understood that different second application interfaces may belong to the same application program or to different application interfaces. Here, no restrictive description is given to the application program to which the second application interface belongs.

[0009] Here, this application does not make a restrictive description of the correspondence between M second application interfaces and N second rendering threads. For example, M can be equal to N. Specifically, the M second application interfaces can each correspond to a second rendering thread, and each second rendering thread can be used to render a second application interface. For another example, M can be greater than N. Specifically, one second rendering thread can be used to render multiple second application interfaces. For another example, M can be less than N. The specific example can be found in the specific description below, which will not be repeated here.

[0010] In addition, the first buffer and the second buffer may be one buffer or a plurality of buffers for implementing buffer rotation based on a buffer rotation mechanism. For example, the second buffer corresponding to one or more of the M second application interfaces may be a plurality of buffers. Here, no restrictive description is given to the number of first buffers corresponding to the first application interface and the number of second buffers corresponding to each second application interface. If the first buffer is a plurality of buffers, generally speaking, the first rendering thread may serially apply for the plurality of buffers included in the first buffer. Accordingly, if the second cache area corresponding to the second application interface is a plurality of buffers, generally speaking, the second rendering thread may serially apply for the plurality of buffers included in the second buffer.

[0011] It can be understood that a rendering thread serially applying for multiple buffers does not affect the electronic device's parallel allocation of buffers for multiple rendering threads. Figure 2b In the description, the allocation service allocates the specific contents of the buffer 101 and the buffer 200 in parallel based on the first allocation buffer thread 12 and the second allocation buffer thread 22, which will not be described in detail here.

[0012] In an example, the M second application interfaces may be application interfaces that need to be displayed by the first application, the second application, and the third application described below. Correspondingly, the N second rendering threads may be rendering thread 11 of the first application, rendering thread 21 of the second application, and rendering thread 31 of the third application described below. Correspondingly, the multiple second buffers may be buffer 100, buffer 200, and buffer 300 described below.

[0013] Based on the above content, 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 serially for the electronic device to respond to the request for buffer application sent by it after applying for the buffer. The delay between the second rendering thread sending the request for buffer application and extracting the buffer is greatly shortened, and the waiting time required before it draws and displays content based on the buffer is shortened. It can be understood that after multiple rendering threads send the request for buffer application, since the electronic device responds to each request in parallel, each rendering thread can extract the buffer and start drawing in a relatively short time. Therefore, it effectively avoids the problems of application interface display freeze, frame drop, etc. caused by the long delay in waiting for the allocation of buffer in the process of displaying multiple application interfaces at the same time.

[0014] In a 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 interfaces of the first application; and the M second application interfaces also include a second application interface U3 of the second application.

[0015] Here, the electronic device can, based on the switching instruction, display the application interface of the second application on the basis of displaying the application interface of the first application, so as to display two application interfaces at the same time. Here, the first application interface U1 displayed before receiving the switching instruction may be the second application interface U2 displayed after the switching, and the second application interface U2 displayed after the switching may also be different from the first application interface U1 displayed before the switching. Here, no restrictive description is made on the application interface displayed by the first application before and after the switching. The second rendering thread of the second application interface U2 displayed after the switching and the second rendering thread of the second application interface U3 may both apply for a buffer, and then the electronic device may allocate the buffer required to display the second application interface U2 and the buffer required to display the second application interface U3 in parallel. This can shorten the time required to display the second application interface U2 and the second application interface U3, and avoid problems such as freeze and frame drop in the application interface display.

[0016] Specifically, the reason why the second application interface U2 displayed after the switch needs to reapply for the buffer may be that the window sizes of the first application interface U1 displayed before the switch and the second application interface U2 displayed after the switch are obviously different, and / or the amount of data that needs to be displayed in the first application interface U1 displayed before the switch and the second application interface U2 displayed after the switch are obviously different. The reason why the second application interface U3 displayed after the switch needs to reapply for the buffer may be that the second application is running for the first time, or the second application is switched from background operation to foreground operation. It can be understood that the present application does not make restrictive explanations on the specific reasons for the second application interface U2 and the second application interface U3 to reapply for the buffer.

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

[0018] Here, the electronic device may simultaneously display the second application interface U2 and the second application interface U3 by split-screen display, by superimposing another second application interface on a second application interface based on a floating window, etc. This application does not make any restrictive description on the specific display method of the second application interface U2 and the second application interface U3.

[0019] In a possible implementation of the first aspect above, the switching instruction is used to instruct display of a multitasking interface on the desktop, the multitasking interface includes M second application interfaces, the M second application interfaces are application interfaces of M second applications, wherein 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 a second rendering thread 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 an application interface of a desktop application of an electronic device. Exemplarily, there may be M second applications running in the background of the electronic device, and correspondingly, there may also be M second application interfaces included in the multitasking interface. Therefore, it can be understood that in order to display the multitasking interface, M second rendering threads of M background-running applications are required to render their respective second application interfaces, and at least one second rendering thread of the desktop application is required 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 a possible implementation of the first aspect above, the second rendering thread corresponding to the desktop application includes: a second rendering thread corresponding to the multi-tasking interface; or a second rendering thread corresponding to the multi-tasking interface and a second rendering thread corresponding to the negative one screen interface.

[0022] Here, in an example manner, since the desktop application is highly associated with the negative one screen application, for example, when the user uses the desktop application to display the multitasking interface or the desktop interface, it is more likely to switch to the negative one screen interface based on user operations such as sliding the interface. Therefore, most electronic device manufacturers will set a policy that instructs the rendering thread of the negative one screen application to apply for a buffer to prepare for displaying the negative one screen interface when the rendering thread of the desktop application reapplies for the buffer. Therefore, under this policy, the second rendering thread of the desktop application corresponding to the second rendering thread of the desktop application can include a second rendering thread of the desktop application corresponding to the multitasking interface and a second rendering thread of the negative one screen application corresponding to the negative one screen interface.

[0023] Here, the negative first screen interface may be a system application interface including a series of customized tools (widgets), news summary, quick operation, search box or other service content. The user can access the negative first screen by sliding operation on the desktop interface.

[0024] In another example, when the electronic device displays the multitasking interface, it may also display the desktop interface. Figure 1 and Figure 5The schematic diagram of the multitasking interface shown in FIG. 1 shows that the multitasking interface can be displayed superimposed on the desktop interface. Based on this display mode, the second rendering thread corresponding to the multitasking interface can be only one, and the superimposed multitasking interface and the desktop interface can be rendered simultaneously based on the one second rendering thread. Alternatively, the multitasking interface can correspond to two second rendering threads, wherein one second rendering thread can be used to render the multitasking interface, and the other second rendering thread can be used to render the desktop interface.

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

[0026] Here, a switching instruction for displaying a multitasking interface may be a swiping operation by a user at the bottom of the screen of an electronic device.

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

[0028] In an example manner, the M second application interfaces may be the application interfaces that need to be displayed by the first application, the second application, and the third application described below. Correspondingly, the N second rendering threads may be 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 described below. Correspondingly, the multiple second buffers may be the buffer 100, the buffer 200, and the buffer 300 described below. The allocation thread may be the allocation buffer thread described below, and the N allocation threads may be the first allocation buffer thread 12, the second allocation buffer thread 22, and the third allocation buffer thread 32 described below.

[0029] Therefore, based on the display method provided by the present 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, so as to avoid problems such as freeze and frame skipping when the electronic device displays the application interfaces of the first application, the second application and the third application at the same time.

[0030] In a possible implementation of the first aspect above, the electronic device includes a first service, the first service is used to allocate a buffer, the first service includes a first interface, and based on N allocation threads, the buffer is allocated in parallel to N second rendering threads, including: a first allocation thread among the N allocation threads calls the first service, and allocates a buffer to a second rendering thread corresponding to the first allocation thread in a first allocation period; a second allocation thread among the N allocation threads calls the first service, and allocates a buffer to a second rendering thread corresponding to the second allocation thread in a second allocation period; wherein the first allocation period overlaps or partially overlaps with the second allocation period.

[0031] Here, the first service may be the allocation service described below, such as Android TM vendor.qti.hard ware.display.allocator-service in the system. The first service may create a corresponding allocation buffer thread for the rendering thread in response to the buffer request sent by the rendering thread, and allocate a buffer for the rendering thread corresponding to the allocation buffer thread based on the calling of the first interface by the allocation buffer thread.

[0032] For example, the first service may create N allocation threads corresponding to the N second rendering threads in response to the buffer request sent by the N second rendering threads, and allocate buffers for the N second rendering threads corresponding to the N allocation threads based on the call of the first interface by the N allocation threads. The first interface may be an interface for allocating buffers in the allocation service described below, for example, an 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: a period of time from the moment when the allocation of the buffer starts to the moment when the allocation of the buffer is completed. Figure 2a Taking the first allocation buffer thread 12 in the example, the first allocation period may be from time t05 to time t06 of the allocation buffer 100.

[0034] It can be understood that based on N allocation threads, N second rendering threads are allocated buffers in parallel, 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. It can be understood that at this time, the allocation service can allocate two buffers at the same time. At most, the N allocation periods of the N allocation threads overlap or partially overlap. It can be understood that at this time, the allocation service can allocate N buffers at the same time. Here, no restrictive description is given to the number of buffers allocated in parallel.

[0035] In a possible implementation of the first aspect above, the first allocation period overlaps or partially overlaps 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 description is given to the specific situation of parallel allocation of buffers. As long as at least two corresponding allocation periods of N allocation threads overlap in time sequence, including overlap in time points, it can be considered that the allocation service is in parallel allocation of buffers.

[0037] In a possible implementation of the first aspect above, the first service also includes a first lock, wherein a 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 may be buffer_lock in vendor.qti.hardware.display.allocator-service. The first variable may be a dma_legacy_dev_fd variable.

[0039] Taking the example that the first service is vendor.qti.hardware.display.allocator-service, the first interface is the AllocBuffer interface in vendor.qti.hardware.display.allocator-service, and the first lock is buffer_lock in vendor.qti.hardware.display.allocator-service, since the AllocBuffer interface is in the scope of buffer_lock, the AllocBuffer interface can only be called serially by the buffer allocation thread, that is, only after one buffer allocation thread completes the buffer allocation, another buffer allocation thread can call the AllocBuffer interface. Therefore, the AllocBuffer interface can be set outside the scope of buffer_lock so that the AllocBuffer interface can be called in parallel by multiple buffer allocation threads.

[0040] It can be understood that the above method can achieve the purpose of allocating multiple buffers in parallel for the first service, and further, can achieve the effect of avoiding the phenomenon of frame freeze and frame drop when displaying multiple application interfaces.

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

[0042] Here, continuing the above example, since the dma_legacy_dev_fd variable in the interface is prohibited from being read and written concurrently, therefore, after the AllocBuffer interface is set outside the scope of buffer_lock, in order to prevent the dma_legacy_dev_fd variable from being read and written concurrently, the dma_legacy_dev_fd variable can be set to a local variable type. It can be understood that for the dma_legacy_dev_fd variable of the local variable type, each thread and / or module that calls the AllocBuffer interface has a corresponding dma_legacy_dev_fd variable value, and the modification of the variable value by each thread and / or module will not affect each other. Therefore, the dma_legacy_dev_fd variable outside the scope of buffer_lock can be effectively avoided from being read and written concurrently. In this way, the allocation buffer exception caused by the concurrent reading and writing of the dma_legacy_dev_fd variable is prevented, and then, it is ensured that the M second application interfaces can be displayed normally.

[0043] In a 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 a local variable type; and when the first allocation buffer thread that calls the first interface is destroyed, all variable values ​​of the first variable are cleared based on the first global set.

[0044] Here, continuing the above example, since each thread and / or module calling the AllocBuffer interface needs to clear the dma_legacy_dev_fd variable value when it is destructed. For example, after the allocation buffer thread completes the allocation buffer, it is necessary to clear the dma_legacy_dev_fd variable value. Therefore, after the dma_legacy_dev_fd variable is set to the local variable type, the scope can be set to a global set in the AllocBuffer interface, for example, a set set can be set in the AllocBuffer interface, and the set is used to save all dma_legacy_dev_fd variable values. Then, when the thread and / or module calling the AllocBuffer interface is destructed, the dma_legacy_dev_fd variable value can be cleared globally by clearing the set. In this way, the allocation buffer exception caused by the dma_legacy_dev_fd variable not being cleared globally during destructing can be prevented, and then, it is ensured that the M second application interfaces can be displayed normally.

[0045] In a second aspect, the present application provides an electronic device comprising: one or more processors; one or more memories; one or more memories storing one or more programs, wherein when one or more programs are executed by one or more processors, the electronic device executes the display method provided by the first aspect and various possible implementations of the first aspect.

[0046] In a third aspect, the present application provides a computer-readable medium having instructions stored thereon, which, when executed on a computer, causes the computer to execute the display method provided by the first aspect and various possible implementations of the first aspect.

[0047] In a fourth aspect, the present application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the display method provided by the above-mentioned first aspect and various possible implementations of the above-mentioned first aspect.

[0048] The beneficial effects of the second to fourth aspects mentioned above can be referred to the relevant descriptions in the first aspect mentioned above and various possible implementations of the first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 The figure shows a scenario schematic diagram of a plurality of applications applying for a buffer zone from an allocation service provided by the present application;

[0050] Figure 2a The figure shows a timing diagram of a plurality of applications serially applying for buffers from an allocation service provided by the present application;

[0051] Figure 2b The figure shows a timing diagram of a plurality of applications applying for buffers from an allocation service in parallel, provided by an embodiment of the present application;

[0052] Figure 2c Another timing diagram of multiple applications serially applying for buffers from an allocation service provided by the present application is shown;

[0053] Figure 2d The figure shows another timing diagram of multiple applications applying for buffers from the allocation service in parallel provided by an embodiment of the present application;

[0054] Figure 2e The figure shows a timing diagram of another method provided by the present application in which multiple applications serially apply for buffers from an allocation service;

[0055] Figure 2f The figure shows a timing diagram of another embodiment of the present application in which multiple applications apply for buffers from the allocation service in parallel;

[0056] Figure 3 The figure is a flow chart of an allocation service provided by an embodiment of the present application allocating buffers to multiple applications in parallel;

[0057] Figure 4 The figure shows an interactive schematic diagram of an allocation service provided by an embodiment of the present application allocating buffers to multiple applications in parallel;

[0058] Figure 5 Shown is a schematic diagram of a multi-tasking interface provided by an embodiment of the present application;

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

[0060] Figure 7 The figure shows a software structure block diagram of a mobile electronic device 1A provided in an embodiment of the present application. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0062] It can be understood that the display method provided in the embodiments of the present application can be applicable to electronic devices including but not limited to mobile phones, tablet computers, desktops, laptops, handheld computers, netbooks, as well as augmented reality (AR) and virtual reality (VR) devices, smart TVs, smart watches and other wearable devices, servers, mobile email devices, car devices, portable game consoles, portable music players, reader devices, televisions in which one or more processors are embedded or coupled, or other electronic devices that can access the Internet.

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

[0064] Based on the foregoing, it can be known that in a scenario where multiple applications of an electronic device simultaneously apply for a buffer from an allocation service, since the allocation service serially allocates buffers to each application, the application with a later application order may wait for a longer time to apply for the buffer, thereby increasing the time it takes for the application to draw and render the interface, which may cause the display process of the application interface to freeze or drop frames. It can be understood that each rendering thread is in a state of applying for a buffer before applying for a buffer. The aforementioned multiple applications simultaneously applying for a buffer from the allocation service may include the rendering threads of multiple applications being in a state of applying for a buffer within a certain period of time. Here, no restrictive description is made on the start and end times for the rendering threads of each application to apply for a buffer.

[0065] For example, Figure 2a A timing diagram showing the simultaneous application of buffers by rendering threads of a first application, a second application, and a third application 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 apply for a buffer from the allocation service of the electronic device based on the initialization operation of the main thread of the corresponding application. Furthermore, the allocation service can create a first allocation buffer thread 12 for allocating a buffer to the rendering thread 11 of the first application, a second allocation buffer thread 22 for allocating a buffer to the rendering thread 21 of the second application, and a third allocation buffer thread 32 for applying for a buffer to the rendering thread 31 of the third application. Here, the initialization operation of the main thread of the application can occur in scenarios such as the first run of the application, switching from background operation to foreground operation, etc. In addition, when the window size of the application interface that the application needs to display and / or the amount of data to be displayed change significantly, the rendering thread of the application may also apply for a buffer from the allocation service of the electronic device. Here, the above-mentioned scenario of applying for a buffer based on the initialization operation of the main thread is only an example, and this application does not restrict the specific scenario of the rendering thread of the application applying for a buffer.

[0067] For example, see Figure 2a From time t01 to time t04, rendering thread 11, rendering thread 21 and rendering thread 31 are all in the state of applying for a buffer, that is, Figure 2a A scenario is shown in which a first application, a second application and a third application simultaneously apply for a buffer zone from an allocation service. Below, the process of the first application applying for a buffer zone is specifically described by taking the first application having a later application sequence as an example.

[0068] Specifically, in this scenario, the main thread of the first application starts initialization at time t01. Based on the initialization operation, the rendering thread of the first application can apply for buffer 100 from the allocation service. However, since the interface for allocating buffers in the allocation service (e.g., AllocBuffer interface) is protected by a lock that limits the interface to be accessed serially (i.e., the interface can only be accessed by one thread or module at a time), each buffer allocation thread can only apply for buffers serially for its corresponding rendering thread. It should be understood that the lock used to limit the interface to be accessed serially can be a mutex lock, a spin lock, etc., and no restrictive description is given here on the type of the lock.

[0069] See also Figure 2a , the first buffer allocation thread 12 can only start to allocate buffer 100 for rendering thread 11 after the second buffer allocation thread 22 completes the allocation of buffer 200 for rendering thread 21, and the third buffer allocation thread 32 completes the allocation of buffer 300 for rendering thread 31. For example, the second buffer allocation thread 22 and the third buffer allocation thread 32 serially complete the allocation of buffer 200 and buffer 300 at time t05, so the first buffer allocation thread 11 can only start to apply for buffer 100 at time t05.

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

[0071] It can be understood that in this scenario, the rendering thread 11 is always in a state of waiting for extracting the buffer 100 from time t03 to time t06. If the rendering thread 11 waits too long for extracting the buffer 100, the display process of the application interface of the first application will be stuck or the frame will be dropped.

[0072] In order to improve the efficiency of applying for buffers for rendering threads of an application, the present application provides a display method, in which an allocation service can apply for buffers for each rendering thread in parallel when receiving buffer application requests sent by multiple rendering threads (for example, rendering threads of different applications). In other words, the allocation service can start allocating buffers for another rendering thread before the allocation service has finished allocating buffers for one rendering thread.

[0073] In this way, when the allocation service allocates buffers for the multiple rendering threads, it does not need to wait for the buffer corresponding to one rendering thread to be applied for before applying for the buffer for the next rendering thread. In this way, the time required for each rendering thread to wait for the buffer to be extracted can be shortened, avoiding the display interface freeze and frame skipping caused by too long waiting time, improving the smoothness of the display interface and improving the user experience.

[0074] In some embodiments, each application may apply for multiple buffers from the allocation service based on a buffer rotation mechanism to implement the circular use of the buffer. It is understandable that for the scenario where each application needs to apply for multiple buffers from the allocation service in series, if the allocation service uses the aforementioned Figure 2a The solution shown allocates buffers to different applications in series, and the delay in responding to buffer requests of applications with later application order will be greatly increased. Therefore, based on the display method provided by the present application, the effect of improving the smoothness of the display interface under the buffer rotation mechanism will be more obvious.

[0075] In some embodiments, the lock corresponding to the buffer allocation interface in the allocation service that restricts the interface to be accessed only serially can be canceled, or the range of the lock can be adjusted so that different buffer allocation threads can call the buffer allocation interface in parallel to allocate buffers for rendering threads of different applications. TM The AllocBuffer interface in the system can cancel the buffer_lock that restricts the interface to be accessed only serially, or set the AllocBuffer interface outside the scope of the buffer_lock.

[0076] Thus, illustratively, Figure 2b A timing diagram is shown in which rendering threads of a first application, a second application, and a third application in an electronic device simultaneously apply for a buffer based on the display method provided in the present application.

[0077] See also Figure 2b, the first buffer allocation thread 12, the second buffer allocation thread 22 and the third buffer allocation thread 32 can allocate buffer 100, buffer 200 and buffer 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. Moreover, even if the second buffer allocation thread 22 does not complete the allocation of buffer 200 before t04, the third buffer allocation thread 32 can also allocate buffer 300 for the rendering thread 31 of the third application in parallel before starting at time t01 before time t04, 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 apply for the buffer 100. Then, the allocation service can create the first buffer allocation thread 12, and the first buffer allocation thread 12 can start allocating the buffer 100 for the rendering thread 11 at time t01.

[0079] Here, the first buffer allocation thread 12 can complete the allocation of the 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 start to extract the buffer. However, since the first buffer allocation thread 12 has completed the allocation 100 at time t06' before time t03, the rendering thread 11 can extract the buffer 100 at time t03 and draw the interface content based on the buffer 100.

[0080] It is understandable that compared with the above Figure 2a , the rendering thread 11 is in a state of waiting for the buffer 100 to be extracted from time t03 to time t06. Furthermore, the interface display process of the first application may be stuck, dropped frames, etc. due to the long waiting time for extracting the buffer 100. However. Based on the display method provided by this application, see Figure 2b , the rendering thread 11 can extract the buffer 100 and start drawing at time t03 when receiving the drawing instruction, so there is no need to wait for the buffer 100 to be extracted. Obviously, the display method provided by the present application can effectively avoid the problems of freezing and frame dropping caused by the long waiting time for extracting the buffer.

[0081] Furthermore, one or more of the rendering thread 11, the rendering thread 21, and the rendering thread 31 may also apply for multiple buffers based on a buffer rotation mechanism. For example, the rendering thread 11 also needs to apply for the buffer 101 (not shown in the figure). The rendering thread 11 completes the application for the buffer 100 at time t06', and then, it can continue to apply for the buffer 101 at any time after time t06'. For example, the first buffer allocation thread 12 can start allocating the buffer 101 at time t05' based on the request for applying for the buffer 101 sent by the rendering thread 11. See Figure 2b At 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 buffer 101 and buffer 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 the rendering thread 11 applying for buffer 100 and buffer 101 is a serial application, but the process of the allocation service allocating buffers to different rendering threads is a parallel allocation. That is, each rendering thread can apply for multiple buffers in series, and the allocation service can allocate buffers to different rendering threads in parallel.

[0082] In addition, based on the above Figure 2a A schematic diagram showing a buffer allocation thread serially allocating buffers, Figure 2c The diagram shows the execution timing of serially allocating buffers in a scenario where the buffer allocation thread may enter a non-running state.

[0083] Exemplarily, in some scenarios, if the electronic device is in an overloaded state with a large number of tasks being executed simultaneously, the first allocation buffer thread 12, the second allocation buffer thread 22, and the third allocation buffer thread 32 may all enter a non-operating state due to the low task priority and inability to seize CPU resources. Here, the non-operating state may be a waiting state for running (runnable). It can be understood that each allocation buffer thread can allocate a buffer for the corresponding rendering thread only in the running (running) state. Therefore, each allocation buffer thread may cause the time required to allocate the buffer to be longer due to entering the runnable state.

[0084] For example, see Figure 2c, the second allocation buffer thread 22 and the third allocation buffer thread 32 may enter the runnable state multiple times, resulting in the serial completion of the allocation buffer 200 and the buffer 300 until time t15. Further, the first allocation buffer thread 12 may not start to allocate the buffer 100 until time t15. Moreover, the first allocation buffer thread 11 may also enter the runnable state multiple times, resulting in a longer time required to allocate the buffer 100. For example, the first allocation buffer thread 11, the second allocation buffer thread 22, and the third allocation buffer thread 32 enter the runnable state multiple times, which may result in the first allocation buffer thread 12 not completing the allocation buffer 100 until time t16.

[0085] In this scenario, the rendering thread 11 is in a state of waiting to fetch the buffer 100 from time t13 to time t16. Figure 2a Obviously, the time that the rendering thread 11 of the first application waits for fetching the buffer 100 from time t13 to time t16 is too long.

[0086] If the display method provided by the present application is used, in a scenario where the buffer allocation thread may enter a non-operating state, multiple buffer allocation threads may also allocate buffers in parallel. Figure 2d Shows Figure 2c In the scenario shown, a schematic diagram of the execution timing after the display method provided by the present application is adopted.

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

[0088] like Figure 2d As shown, from time t10 to time 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 respectively allocate buffer 100, buffer 200, and buffer 300 for the rendering thread 11 of the first application, the rendering thread 12 of the first application, and the rendering thread 13 of the third application in parallel. Here, the rendering thread 12 and the rendering thread 13 are not shown. Therefore, even if the first allocation buffer thread 12 enters the runnable state multiple times, the allocation buffer 100 can be completed at time t14'. Compared with the situation shown in FIG. 2C, the time for the rendering thread 11 to wait for the extraction of the buffer 100 can be effectively shortened.

[0089] In this case, based on the drawing instruction issued by the main thread 10 of the first application at time t12, the rendering thread 11 can start extracting the buffer 100 at time t13 after receiving the drawing instruction, and extract the buffer 100 at time t14' when the first buffer allocation thread 12 completes the allocation of the buffer 100, so as to start the drawing operation at time t14'. It can be understood that the time length for the rendering thread 11 to wait for extracting the buffer 100 is only from time t13 to time t14'. Figure 2b In the example, the rendering thread 11 waits for the buffer 100 from time t13 to time t16. Obviously, the time for the rendering thread 11 to wait for the buffer 100 is greatly shortened based on the display method of the present application. Therefore, the display interface freezes and skips due to the long waiting time for the buffer to be extracted caused by the rendering thread of the application entering the runnable state.

[0090] In addition, based on the above Figure 2a A schematic diagram showing a buffer allocation thread serially allocating buffers, Figure 2e The diagram shows the execution timing of serially allocating buffers in a scenario where the buffer allocation thread may enter an uninterruptible sleep state (D state).

[0091] For example, in some scenarios, if the nodes that the allocation buffer threads corresponding to the first application, the second application, and the third application need to access are occupied by other threads or modules, resulting in the allocation buffer threads being unable to access the nodes, then the allocation buffer threads that are unable to access the nodes may all enter the D state.

[0092] It can be understood that each buffer allocation thread can apply for a buffer for the corresponding rendering thread only in a non-D state, where the non-D state may be a running state, etc. Therefore, each buffer allocation thread may take longer to apply for a buffer due to entering the D state.

[0093] For example, see Figure 2e , the second allocation buffer thread 22 and the third allocation buffer thread 32 may enter the D state multiple times, resulting in the serial completion of the allocation buffer 200 and the buffer 300 until time t25. In addition, the first allocation buffer thread 11 may also enter the D state multiple times, resulting in a longer time required to allocate the buffer 100. For example, the first allocation buffer thread 11, the second allocation buffer thread 22, and the third allocation buffer thread 32 enter the D state multiple times, which may result in the first allocation buffer thread 12 not being able to complete the allocation buffer 100 until time t26.

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

[0095] If the display method provided by the present application is adopted, in a scenario where the buffer allocation thread may enter the D state, multiple buffer allocation threads may also allocate buffers in parallel. Figure 2f Shows Figure 2e In the scenario shown, a schematic diagram of the execution timing after the display method provided by the present application is adopted.

[0096] Exemplarily, for a scenario where the allocation buffer thread may enter the D state, Figure 2f A timing diagram is shown in which rendering threads of a first application, a second application, and a third application in an electronic device simultaneously apply for a buffer based on the display method provided in the present application.

[0097] For example, see Figure 2f , the main thread 10 of the first application starts the initialization operation at time t21, so that the rendering thread 11 of the first application starts to apply for the buffer 100 from the allocation service at time t21. Based on the display method provided by the present application, the first buffer allocation thread 12 can start to allocate the buffer 100 for the rendering thread 11 at time t21.

[0098] like Figure 2f As shown, from time t20 to time t25', the first buffer allocation thread 12, the second buffer allocation thread 22, and the third buffer allocation thread 32 can allocate buffer 100, buffer 200, and buffer 300 to the rendering thread 11, the rendering thread 12, and the rendering thread 13 in parallel. Here, the rendering thread 12 and the rendering thread 13 are not shown. Therefore, even if the first buffer allocation thread 12 enters the D state multiple times, the buffer 100 can be allocated at 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 when the drawing instruction is received, and extract the buffer 100 at time t26' when 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 can be understood that the time length for the rendering thread 11 to wait for fetching the buffer 100 is only from time t23 to time t26'. Figure 2cIn the example, the rendering thread 11 waits for the buffer 100 from time t23 to time t26. Obviously, the time for the rendering thread 11 to wait for the buffer 100 is greatly shortened based on the display method of the present application. Therefore, the display interface freezes and skips due to the long waiting time for the buffer to be extracted caused by the rendering thread of the application entering the D state.

[0101] In some embodiments, the lock that limits the interface to be accessed only serially can be used to protect the global variables in the interface from being read and written concurrently. Therefore, after canceling the lock that limits the interface to be accessed only serially corresponding to the interface used to allocate the buffer in the allocation service, or adjusting the scope of the lock, the display method provided by the present application can also set the global variable protected by the lock as a local variable to prevent the variable from being read and written concurrently. For example, for Android TM The dma_legacy_dev_fd_ variable in the AllocBuffer interface of the system that prohibits concurrent reading and writing can be modified to a local variable type. This allows each allocation buffer thread that calls the interface to have a corresponding dma_legacy_dev_fd variable value, and the modification of the variable value by each thread does not affect each other. In this way, while implementing the parallel allocation of buffers by the allocation buffer thread, it can avoid abnormal calls to the interface caused by concurrent reading and writing of the dma_legacy_dev_fd variable by the allocation buffer thread.

[0102] In some embodiments, a global variable that is prohibited from being read and written concurrently may need to clear the variable value of the global variable during destruction. Therefore, the display method provided by the present application can also set a set of global scopes and save the variable values ​​of all global variables in the set. Furthermore, when the allocation buffer thread accessing the interface is destroyed, all variable values ​​of the global variable can be cleared based on the set. For example, a global set set can be established to save all variable values ​​of the dma_legacy_dev_fd_ variable. In this way, the destruction exception of the allocation buffer thread can be further avoided.

[0103] Below, the display method provided by the present application will be described in detail with reference to the accompanying drawings.

[0104] Specifically, Figure 3 According to an embodiment of the present application, a flow chart of an allocation service allocating buffers to rendering threads of multiple applications based on the display method provided by the present application is shown.

[0105] Understandably, Figure 3 The execution subject of each step of the illustrated process may be the allocation service in the electronic device 1A. For the convenience of description, the execution subject of each step will not be repeated in the following description of each step.

[0106] It should also be stated that the steps in the methods and processes in the embodiments of the present application are numbered for ease of reference, rather than to limit the order of precedence. If there is an order between the steps, the text description shall prevail.

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

[0108] 301: Receive buffer application requests sent by multiple rendering threads.

[0109] For example, the allocation service may receive buffer application requests from multiple rendering threads within a certain time period, and thus may need to allocate buffers to rendering threads of multiple applications at the same time.

[0110] Here, the multiple rendering threads that send buffer application requests to the allocation service within a certain time period may be rendering threads corresponding to different applications. Here, no restrictive description is given to the rendering threads that send buffer application requests to the allocation service.

[0111] For example, the multiple rendering threads that send buffer request requests to the allocation service may be the aforementioned Figure 2a and Figure 2b 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. Here, no restrictive description is given to the time when the rendering threads of multiple applications send the request for buffer. It can be understood that the rendering threads of multiple applications 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 to the rendering threads of multiple applications can be understood as the process of the allocation service allocating buffers to the rendering threads of multiple applications having a timing overlap.

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

[0113] Exemplarily, based on the aforementioned step 301, after receiving the buffer allocation request sent by each rendering thread, the allocation service may create a corresponding buffer allocation thread for each rendering thread.

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

[0115] In an example manner, each time the allocation service receives a buffer application request sent by a rendering thread, it may create a corresponding buffer allocation thread for the rendering thread to execute a process of allocating a buffer for the rendering thread.

[0116] Specifically, the rendering thread of the application program may apply for a buffer from the allocation service, so that the allocation service creates an allocation buffer thread for the application program to allocate the buffer.

[0117] In addition, to achieve the recycling of buffers, the rendering thread of the application may apply for multiple buffers from the allocation service based on the buffer rotation mechanism. In this case, if the allocation service receives multiple buffer application requests sent by a rendering thread within a period of time, it can create an allocation buffer thread for the rendering thread to allocate the aforementioned multiple buffers; it can also create multiple allocation buffer threads for the rendering thread to allocate the aforementioned multiple buffers in parallel. Here, no restrictive description is made on the specific process and implementation method of the allocation service creating the allocation buffer thread.

[0118] Specifically, in an 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 buffer allocation threads for the desktop application in response to the buffer application request sent by the rendering thread of the desktop application, and may create one or more buffer allocation threads for the negative-one-screen application in response to the buffer application request sent by the rendering thread of the negative-one-screen application.

[0119] 303: Allocate buffers to rendering threads corresponding to the respective buffer allocation threads in parallel based on the established multiple buffer allocation threads.

[0120] For example, see Figure 2a and Figure 2b The 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 seizes the processor resources, it can call the interface for allocating buffers to allocate buffers for the corresponding rendering threads. That is, at the same time, multiple buffer allocation threads can call the interface for allocating buffers to allocate buffers for their corresponding rendering threads.

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

[0123] Here, the AllocBuffer interface in vendor.qti.hardware.display.allocator-service is in the scope of buffer_lock, where buffer_lock is a lock to prevent concurrent reading and writing of the dma_legacy_dev_fd variable in the AllocBuffer interface. It can be understood that since the AllocBuffer interface is in the scope of buffer_lock, the AllocBuffer interface can only be called serially by the buffer allocation thread, that is, only after one buffer allocation thread completes the buffer allocation can another buffer allocation thread call the AllocBuffer interface. Therefore, the AllocBuffer interface can be set outside the scope of buffer_lock so that the AllocBuffer er interface can be called in parallel by multiple buffer allocation threads.

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

[0125] In addition, if there is no variable in the interface that prohibits concurrent reading and writing, the lock can be directly deleted. It can be understood that by deleting the lock that restricts the interface to be only accessed serially, the interface for allocating buffers can also be called in parallel.

[0126] Furthermore, let's continue to take vendor.qti.hardware.display.allocator-service as an example. Since the dma_legacy_dev_fd variable in the interface is prohibited from being read and written concurrently, after the AllocBuffer interface is set outside the scope of buffer_lock, in order to prevent the dma_legacy_dev_fd variable from being read and written concurrently, the dma_legacy_dev_fd variable can be set to a local variable type. It can be understood that for the dma_legacy_dev_fd variable of the local variable type, each thread and / or module that calls the AllocBuffer interface has a corresponding dma_legacy_dev_fd variable value, and the modifications of the variable value by each thread and / or module will not affect each other. Therefore, the dma_legacy_dev_fd variable outside the scope of buffer_lock can be effectively prevented from being read and written concurrently.

[0127] Here, it can be understood that the thread and / or module that calls the AllocBuffer interface includes but is not limited to the aforementioned buffer allocation thread.

[0128] In addition, since each thread and / or module that calls the AllocBuffer interface needs to clear the dma_legacy_dev_fd variable value when it is destroyed. For example, after the allocation buffer thread completes the allocation buffer, it is necessary to clear the dma_legacy_dev_fd variable value. Therefore, after the dma_legacy_dev_fd variable is set to a local variable type, a set with a global scope can be set in the AllocBuffer interface. For example, a set set can be set in the AllocBuffer interface, and the set is used to save all dma_legacy_dev_fd variable values. Furthermore, when the thread and / or module that calls the AllocBuffer interface is destroyed, the dma_legacy_dev_fd variable value can be globally cleared by clearing the set.

[0129] Next, in conjunction with the specific process of the allocation service allocating buffers for multiple applications in parallel, the interaction process between each application and the allocation service is described in detail by taking the allocation service allocating buffers for the first application, the second application and the third application as an example.

[0130] For example, Figure 4 Taking allocating services and allocating buffers to rendering threads of the first application, the second application, and the third application as an example, an interaction schematic diagram is shown.

[0131] It is understandable that the first application, the second application and the third application may be third-party applications or system applications. This application does not restrict 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), and the rendering thread 11 may include a rendering thread 110 and a rendering thread 111. The main thread 10 may perform initialization operations in scenarios such as the first run, switching from background run to foreground run, etc. Moreover, after the main thread 10 is initialized, it may send a drawing instruction to the rendering thread 11. The rendering thread 111 in the rendering thread 11 may apply for a buffer 100 from the allocation service based on the initialization operation of the main thread 10, so that the allocation service creates a first allocation buffer thread 12 corresponding to the first application, and allocates a buffer 100 to the rendering thread 11 through the first allocation buffer thread 12. The rendering thread 110 in the rendering thread 11 may extract the buffer 100 allocated by the allocation service after receiving the drawing instruction sent by the main thread 10, so as to perform drawing work in the extracted buffer 100.

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

[0134] It can be understood that the operations performed by the main thread 20 and the main thread 30 are substantially the same as the operations performed by the main thread 10; the operations performed by the rendering thread 210 and the rendering thread 310 are substantially the same as the operations performed by the rendering thread 110; and the operations performed by the rendering thread 211 and the rendering thread 311 are substantially the same as the operations performed by the rendering thread 111. No further description will be given here.

[0135] In addition, it is understandable that Figure 4In the example, only the first application, the second application, and the third application each apply for a buffer from the allocation service. It can be understood that each application can also apply for multiple buffers from the allocation service based on the buffer rotation mechanism to realize the circular use of the buffer. Here, no restrictive description is made on the number of buffers applied by each application to the allocation service. For example, the application can apply for three or four buffers from the allocation service based on the rendering thread. Here, the process of a rendering thread of an application applying for multiple buffers from the allocation service can be performed serially or in parallel. Here, no restrictive description is made on the specific implementation method of each application applying for multiple buffers.

[0136] Specifically, Figure 4 The illustrated interactive flow of the allocation service allocating buffers to multiple applications in parallel may include the following steps:

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

[0138] Exemplarily, based on the initialization operation started by the main thread 20 of the second application at time t40 , the rendering thread 211 of the second application starts to apply for the buffer 200 from the allocation service at time t40 .

[0139] It is understandable that the second application may be run for the first time at time t40, or switched from background running to foreground running at time t40, so that the main thread 20 starts the initialization operation at time t40.

[0140] In addition, when the display interface content and / or the size of the display window required to be displayed by the second application at time t40 change significantly, the rendering thread 211 of the second application may start to apply for the buffer 200 from the allocation service at time t40. Here, no restrictive description is given to the specific scenario in which the rendering thread 211 applies for the buffer from the allocation service.

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

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

[0143] Exemplarily, after receiving the buffer allocation request sent by the rendering thread 211 of the second application at time t40 , the allocation service may create a second buffer allocation thread 22 corresponding to the rendering thread 211 .

[0144] 402 : The second buffer allocation thread 22 allocates the buffer 200 .

[0145] Exemplarily, after being established, the second buffer allocation thread 22 may start allocating the buffer 200 for the rendering thread 211 of the second application at time t40 , and complete the allocation of the buffer 200 at time t45 .

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

[0147] It can be understood that, since the second buffer allocation thread 22 completes the allocation of the buffer 200 at time t45, the rendering thread 211 of the second application can also end sending the application to the allocation service at time t45.

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

[0149] Exemplarily, 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 apply for the buffer 300 from the allocation service at time t41 .

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

[0151] In addition, the scene in which the rendering thread 311 starts to apply for the buffer 300 from the allocation service at time t41 can be specifically referred to the specific description in the aforementioned step 400, which will not be repeated here.

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

[0153] Exemplarily, after the allocation service receives the buffer allocation request sent by the rendering thread 311 of the third application at time t41 , the allocation service may create a third buffer allocation thread 32 .

[0154] 405 : The third buffer allocation thread 32 allocates the buffer 300 .

[0155] Exemplarily, after being established, the third buffer allocation thread 32 may start allocating the 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 the buffer 200 for the second application based on the second allocation buffer thread 22 at time t41, the allocation service is still based on the aforementioned Figure 3 The process of allocating buffers for multiple applications in parallel shown can allocate buffers 300 for the third application at time t41 based on the third buffer allocation thread 32. That is, starting from time t41, the allocation service allocates buffers for the second application and the third application at the same time.

[0157] Furthermore, the third allocation buffer thread 32 completes the allocation of the buffer 300 until time t46. Here, the time taken by the second allocation buffer thread 32 to allocate the buffer 300 is the time from time t41 to time t46. This time may be affected by the fact that the first allocation buffer thread 32 enters the runnable state and / or the D state multiple times. Here, the reason why the allocation buffer thread 32 may enter the runnable state or the D state is as described above and will not be repeated here.

[0158] It can be understood that, since the third buffer allocation thread 32 completes the allocation of the buffer 300 at time t46, the rendering thread 311 of the third application can also end sending the application to the allocation service at time t46.

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

[0160] Exemplarily, the main thread 10 of the first application program may start the initialization operation at time t42. Here, the scenario in which the main thread 10 starts the initialization operation at time t42 can be referred to the specific description in the aforementioned step 400, which will not be repeated here.

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

[0162] Exemplarily, based on the initialization operation performed by the main thread 10 of the first application program at time t42 , the rendering thread 111 of the first application program may start to apply for the buffer 100 from the allocation service at time t42 .

[0163] Here, the scenario in which the rendering thread 111 of the first application starts to apply for the buffer 100 from the allocation service at time t42 can refer to the relevant description in the aforementioned step 400, which will not be repeated here.

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

[0165] Exemplarily, after receiving the buffer allocation request sent by the rendering thread 111 of the first application at time t42 , the allocation service may create a first buffer allocation thread 12 corresponding to the rendering thread 111 .

[0166] 409 : The first buffer allocation thread 12 allocates the buffer 100 .

[0167] Exemplarily, after being established, the first buffer allocation thread 12 may start allocating the 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 the buffer 200 for the second application based on the second allocation buffer thread 22 at time t42, and allocating the buffer 300 for the third application based on the third allocation buffer thread 32, the allocation service is based on the aforementioned Figure 3 The process of allocating buffers for multiple applications in parallel shown can allocate buffers 100 for the first application at time t42 based on the first buffer allocation thread 12. 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 allocation buffer thread 12 completes the allocation of the buffer 100 until time t47. Here, the time taken by the first allocation buffer thread 12 to allocate the buffer 100 is the time from time t42 to time t47. This time may be affected by the first allocation buffer thread 12 entering the runnable state and / or the D state multiple times. Here, the reasons why the first allocation buffer thread 12 may enter the runnable state or the D state are as described above and will not be repeated here.

[0170] It can be understood that, since the first buffer allocation thread 12 completes the allocation of the buffer 100 at time t47, the rendering thread 111 of the first application can also end sending the application to the allocation service at time t47.

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

[0172] Exemplarily, after completing initialization, the main thread 10 of the first application may send a drawing instruction to the rendering thread 110 at time t43.

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

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

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

[0176] Here, it can be understood that compared with the above Figure 2a to Figure 2c The solution of allocating buffers for multiple applications in series by the allocation service shown in the figure takes the process of displaying the application interface of the first application 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 for the extraction of the buffer 100. Since the time interval from the rendering thread 110 receiving the drawing instruction to the extraction of 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 interface content for a long time, resulting in freezes, frame drops, etc. during the interface display process.

[0177] In addition, it can be understood that, for the second application and the third application, the display method provided by the present application also shortens the time required for the rendering thread 210 and the rendering thread 310 to wait for extracting the buffer 200 and the buffer 300.

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

[0179] Exemplarily, the rendering thread 110 of the first application may draw and render the display content corresponding to the first application after fetching the buffer 100 .

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

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

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

[0183] Specifically, in an exemplary scenario, see the aforementioned 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 the multitasking interface based on an upward swipe operation on the display 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. At the same time, the desktop application used to display the multitasking interface switches from background operation to foreground operation. At this time, the rendering thread of the desktop application may request a buffer from the allocation service based on the initialization of the main thread of the desktop application. In addition, since the negative one-screen application is closely related to the use of the desktop application, most electronic device manufacturers will set a display strategy for the negative one-screen application to be initialized when the desktop application is initialized. Furthermore, in Figure 1 In the scenario shown, the rendering thread of the negative one screen application may also request a buffer from the allocation service.

[0184] Furthermore, the desktop application, the negative one screen application and the instant messaging application may simultaneously request a buffer from the allocation service. Figure 3 and Figure 4 The process is essentially the same as allocating buffers in parallel for desktop applications, negative one screen applications, and instant messaging applications. This shortens the time required for the rendering threads of desktop applications, negative one screen applications, and instant messaging applications to wait for buffer extraction. This avoids freezes and frame drops when the user swipes up the display screen to switch from the chat interface to the multitasking interface.

[0185] Here, the process of allocating buffers for the electronic device 1A to allocate services for desktop applications, negative one screen applications and instant messaging applications in parallel can be referred to in the above description. Figure 3 and Figure 4 The detailed description is not given here.

[0186] In addition, when the user of electronic device 1A switches the chat interface to the multitasking interface based on a swipe up operation 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 A schematic diagram of a multitasking interface is shown, in which the multitasking interface 500 includes a chat interface 501 of an instant messaging application, a text message interface 502 of a text message application, a memo interface 503 of a memo application, and a calculation interface 504 of a calculator application. Here, one or more of the rendering threads corresponding to the instant messaging application, the text message application, the memo application, and the calculator application may apply to the allocation service for a buffer to display the corresponding interface content. It can be understood that the multitasking interface may also display the playback interface of a video application, etc. Here, no restrictive description is given to the interface content displayed on the multitasking interface.

[0188] Figure 6 A schematic structural diagram of an electronic device 1A is shown.

[0189] The 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, an earphone interface 170D, a sensor module 180, a button 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, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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 structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the electronic device 1A. In other embodiments of the present application, the electronic device 1A may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0191] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0192] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0193] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, 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. The interface 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 groups of I2C buses. The processor 110 may be coupled to the touch sensor 180K, the charger, the flash, the camera 193, etc. through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through the I2C interface, so that the processor 110 communicates with the touch sensor 180K through the I2C bus interface, thereby realizing the touch function of the electronic device 1A.

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

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

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

[0199] The touch sensor 180K is also called a "touch control device". The touch sensor 180K can be set on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, also called a "touch control screen". The touch sensor 180K is used to detect touch operations acting on or near it. The touch sensor can pass 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 the display screen 194. In other embodiments, the touch sensor 180K can also be set on the surface of the electronic device 1A, which is different from the position of the display screen 194.

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

[0201] The layered architecture divides the software into several layers, each with a clear role and division of labor. The 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 TM Runtime (Android TM 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, the second application, the third application, the desktop application, etc. Among them, 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 an application programming interface (API) and a programming framework for the 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, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0206] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0207] Content providers are used to store and retrieve data and make it accessible to applications. This data can include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

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

[0209] The phone manager is used to provide communication functions of the electronic device 1A, such as management of call status (including connecting, hanging up, etc.).

[0210] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0211] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can automatically disappear after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as a notification of an application running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is prompted in the status bar, a prompt sound is emitted, the electronic device 1A vibrates, the indicator light flashes, etc.

[0212] Android TM Runtime includes core libraries and virtual machines. 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 function that needs to be called by the Java language, and the other part is the Android core library.

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

[0215] The system library may include multiple functional modules, such as surface manager, media libraries, 3D graphics processing library (such as openGL ES), 2D graphics engine (such as SGL), etc.

[0216] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0217] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[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 drawing engine for 2D drawings.

[0220] The hardware abstraction layer is an interface layer between the kernel layer and the hardware circuit, and its purpose is to abstract the hardware. It hides the hardware interface details of a specific platform and provides a virtual hardware platform for the operating system, making it hardware-independent and portable on multiple platforms.

[0221] The hardware abstraction layer may include the aforementioned allocation service. When the rendering thread of an application in the application layer needs to apply for a buffer, a cross-process buffer application may be performed based on the allocation service. Here, the allocation service may be Android TM vendor.qti.hardware.display.allocator-service in the system. In addition, the allocation service may include an interface for applying for a buffer, for example, the interface may be the AllocBuffer interface in vendor.qti.hardware.display.allocator-service.

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

[0223] The embodiments of the present application also provide a computer program product for implementing the display methods provided in the above embodiments.

[0224] The various embodiments of the mechanism disclosed in the present application can be implemented in hardware, software, firmware or a combination of these implementation methods. The embodiments of the present application can be implemented as a computer program module or module code executed on a programmable system, and the programmable system includes 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] A computer program module 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, a 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 with high-level modular language or object-oriented programming language to communicate with the processing system. When necessary, module code can also be implemented with assembly language or machine language. In fact, the mechanism described in this application is not limited to the scope of any specific 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 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, instructions may be distributed over a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine (e.g., computer) readable form, including but not limited to floppy disks, optical disks, optical disks, read-only memories (CD-ROMs), magneto-optical disks, read-only memories (ROM), random access memories (RAM), erasable programmable read-only memories (EPROM), electrically erasable programmable read-only memories (EEPROM), magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in electrical, optical, acoustic, or other forms of propagation signals. Accordingly, machine-readable media include any type of machine-readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer).

[0228] The disclosure of the embodiments of the present application also relates to a computer program product for executing operations in the text, and the computer program product includes: a computer program code, when the computer program code runs on a computer, enables the computer to implement the operations performed by the electronic device 1A in any embodiment in the specification.

[0229] References to "one embodiment" or "an embodiment" in the specification mean that the specific features, structures, or characteristics described in conjunction with the embodiment are included in at least one exemplary implementation or technology disclosed according to the embodiment of the present application. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily all refer to the same embodiment.

[0230] The disclosure of the embodiment of the present application also relates to an operating device for executing the text. The device can be specially constructed for the required purpose or it can include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer-readable medium, such as, but not limited to any type of disk, including a floppy disk, an optical disk, a CD-ROM, a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic or optical card, an application-specific integrated circuit (ASIC) or any type of medium suitable for storing electronic instructions, and each can be coupled to a computer system bus. In addition, the computer mentioned in the specification may include a single processor or may be an architecture involving multiple processors for increased computing power.

[0231] In addition, the language used in this specification has been primarily selected for readability and instructional purposes and may not be selected to describe or limit the disclosed subject matter. Therefore, the present application embodiment disclosure is intended to illustrate rather than limit the scope of the concepts discussed herein.

Claims

1. A display method, applied to an electronic device, characterized in that: The method comprises: Detecting a first instruction to display a first application interface; Allocate a first buffer to a first rendering thread of the first application interface, and render the first application interface based on the first buffer; detecting a switching instruction to switch display of 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 the N second rendering threads corresponding to the M second application interfaces, and the multiple second application interfaces are rendered respectively based on the multiple second buffers, where M is less than or equal to N.

2. The method according to claim 1, characterized in that M is 2, the first application interface U1 and the second application interface U2 among the M second application interfaces are interfaces of the first application; and, The M second application interfaces also include a 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 split screen; Display the second application interface U2 in full screen, and display the second application interface U3 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 instruction is used to instruct to display a multitasking interface on the desktop, the multitasking interface includes the M second application interfaces, the M second application interfaces are application interfaces of M second applications, wherein 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 a second rendering thread corresponding to the desktop application.

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

6. The method according to claim 4, characterized in that The detecting of a switching instruction to switch displaying the first application interface to displaying M second application interfaces includes: The user's upward sliding operation at the bottom of the electronic device screen is detected, and the switching instruction is detected.

7. The method according to any one of claims 1 to 6, characterized in that The parallel allocation of multiple second buffers to the N second rendering threads corresponding to the M second application interfaces includes: Receiving the requests for applying for the buffer zone sent by the N second rendering threads, and creating corresponding allocation threads for the N second rendering threads respectively; Buffers are allocated in parallel to the N second rendering threads based on the N allocation threads.

8. The method according to claim 7, characterized in that The electronic device comprises a first service, the first service is used to allocate a buffer, the first service comprises a first interface, and, The allocating buffers in parallel for the N second rendering threads based on the N allocation threads includes: A first allocation thread among the N allocation threads calls the first service to allocate a buffer to a second rendering thread corresponding to the first allocation thread in a first allocation period; A second allocation thread among the N allocation threads calls the first service and allocates a buffer to a second rendering thread corresponding to the second allocation thread in a second allocation period; wherein the first allocation period overlaps or partially overlaps with the second allocation period.

9. The method according to claim 8, characterized in that The first allocation period overlaps or partially overlaps 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.

10. The method according to claim 8, characterized in that 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 a first variable in the first service from being read and written concurrently.

11. An electronic device, characterized in that: include: one or more processors; One or more memories; the one or more memories store one or more programs, and when the one or more programs are executed by the one or more processors, the electronic device executes the display method described in any one of claims 1 to 10.

12. A computer readable medium, characterized in that The readable medium stores instructions, which, when executed on a computer, enable the computer to execute the display method according to any one of claims 1 to 10.

13. A computer program product, characterized in that The invention comprises a computer program / instruction, which implements the display method according to any one of claims 1 to 10 when executed by a processor.

Images