Refresh rate decision method, electronic equipment, readable storage medium and program product

Abstract

The invention relates to the technical field of electronic equipment, and provides a refresh rate decision method, electronic equipment, a readable storage medium and a program product, and the electronic equipment comprises a target application. The method comprises the steps of running at least one target application in a foreground; for each target application, determining a target frame rate based on a frame rate strategy corresponding to the target application; according to the target frame rate corresponding to the target application, scheduling processor resources for the target application; and determining a first target refresh rate based on the target frame rates of all the target applications, wherein a display screen of the electronic equipment performs picture refresh according to the first target refresh rate. Therefore, according to the method, the refresh rate and the frame rate are decoupled, so that resource supply of the target application can be ensured, mutual interference of multiple target applications in a high-concurrency scene is avoided, and the performance of the target application is ensured.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, and in particular to a refresh rate decision method, electronic device, readable storage medium, and program product. Background Technology

[0002] In recent years, with the improvement of hardware performance in electronic devices (such as mobile phones), especially the advancement of processor and display technology, screens supporting high frame rates have gradually become mainstream. At the same time, to enhance user experience, application developers, particularly game developers, have begun optimizing their applications to support high frame rate displays. Therefore, the refresh rates and frame rates available for selection in electronic devices are increasing. However, existing electronic devices face the problem of not being able to ensure the supply of resources required by applications when making refresh rate and frame rate decisions. Summary of the Invention

[0003] This application provides a refresh rate decision method, an electronic device, a readable storage medium, and a program product to ensure resource supply for a target application and to avoid mutual interference among multiple target applications in high-concurrency scenarios, thereby ensuring the performance of the target application.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0005] In a first aspect, a refresh rate decision method is provided, applied to an electronic device, the electronic device including a target application; the method includes: running at least one target application in the foreground; for each target application, determining a target frame rate based on the frame rate strategy corresponding to the target application; scheduling processor resources for the target application according to the target frame rate corresponding to the target application; determining a first target refresh rate based on the target frame rates of all target applications, and refreshing the screen of the electronic device according to the first target refresh rate.

[0006] In this implementation, the frame rate and refresh rate are decoupled. That is, the target frame rate is determined without relying on the refresh rate; instead, the target application's target frame rate is decided first, and then the target refresh rate is determined based on that frame rate. This isolates the impact of other refresh rate decision scenarios on the target frame rate decision. In other words, even if the target application does not have refresh rate decision authority, it will not affect the target application's decision regarding the corresponding target frame rate, thus ensuring resource supply on the target application's side.

[0007] Furthermore, in high-concurrency scenarios, because the frame rate and refresh rate are decoupled, the target frame rate decision can be made separately for each target application. This allows for resource scheduling based on the target frame rate of each target application, thereby avoiding mutual interference between target applications and meeting the performance requirements of all target applications as much as possible.

[0008] In one possible implementation of the first aspect, the target application includes game applications. Therefore, for performance-intensive applications like games, decoupling frame rate and refresh rate ensures sufficient resource supply even if the game application lacks refresh rate decision-making authority. Furthermore, in multi-game concurrent scenarios, it prevents interference between games, maximizing the performance requirements of all game applications and thus ensuring a superior user gaming experience.

[0009] In one possible implementation of the first aspect, the electronic device also includes a non-target application, which corresponds to at least one application refresh rate, and different application refresh rates correspond to different application scenarios of the non-target application. Based on this, the refresh rate decision method further includes: if at least one non-target application is running in the foreground and the focused window is a window of a non-target application, a second target refresh rate is determined based on a first target refresh rate and the refresh rate of at least one application, and the display screen of the electronic device refreshes the screen according to the second target refresh rate; wherein, the second target refresh rate includes at least one of the first target refresh rate and the refresh rate of at least one application; if there is an application refresh rate greater than the first target refresh rate among the at least one application refresh rates, the second target refresh rate includes the application refresh rate greater than the first target refresh rate; if there is an application refresh rate less than the first target refresh rate among the at least one application refresh rates, the second target refresh rate does not include the application refresh rate less than the first target refresh rate; if all at least one application refresh rate is less than the first target refresh rate, the second target refresh rate only includes the first target refresh rate; when the second target refresh rate only includes the first target refresh rate, the screen is refreshed according to the first target refresh rate; when the second target refresh rate does not only include the first target refresh rate, a refresh rate is selected from the second target refresh rates based on the application scenario of the non-target application for screen refresh.

[0010] In this implementation, considering that in high-concurrency scenarios, in addition to multiple target applications running simultaneously, there may be situations where non-target applications are running simultaneously, when the non-target application is the focus application, a new second target refresh rate is obtained based on the first target refresh rate and the application refresh rate corresponding to the non-target application. The screen is refreshed according to the second target refresh rate, so as to ensure the refresh rate requirements of both target and non-target applications at the same time, thereby improving the user experience in high-concurrency scenarios.

[0011] In another possible implementation of the first aspect, the non-target application includes a desktop application, and the application refresh rate includes a first application refresh rate and a second application refresh rate, wherein the first application refresh rate is greater than the second application refresh rate. Based on this, determining a second target refresh rate based on a first target refresh rate and at least one application refresh rate, and refreshing the screen of the electronic device according to the second target refresh rate, may include: when the second application refresh rate is greater than the first target refresh rate, determining that the second target refresh rate includes both the first and second application refresh rates, and refreshing the screen of the electronic device according to either the first or second application refresh rate based on the application scenario of the non-target application; when the second application refresh rate is less than the first target refresh rate, determining that the second target refresh rate includes both the first application refresh rate and the first target refresh rate, and refreshing the screen of the electronic device according to either the first application refresh rate or the first target refresh rate based on the application scenario of the non-target application; wherein the application scenario corresponding to the first target refresh rate is the same as the application scenario corresponding to the second application refresh rate; when the first target refresh rate is greater than the first application refresh rate, the second target refresh rate is the first target refresh rate, and refreshing the screen of the electronic device according to the first target refresh rate.

[0012] In one possible implementation of the first aspect, the frame rate strategy includes a preset restriction strategy and an overlay strategy; the restriction strategy has a higher priority than the overlay strategy; determining the target frame rate based on the frame rate strategy corresponding to the target application includes: obtaining the target strategy from the frame rate strategies corresponding to the target application according to the strategy pointer; the target strategy includes the frame rate strategy pointed to by the strategy pointer and a frame rate strategy with a higher priority than the frame rate strategy pointed to by the strategy pointer; for the restriction strategy in the target strategy, obtaining the minimum frame rate from the frame rates corresponding to the restriction strategy as the first candidate frame rate; for the overlay strategy in the target strategy, using the frame rate corresponding to the overlay strategy with the highest priority as the second candidate frame rate; wherein, when there is no overlay strategy in the target strategy, the second candidate frame rate is empty; when the first candidate frame rate is less than the second candidate frame rate and less than the previous target frame rate, the first candidate frame rate is used as the target frame rate; when the first candidate frame rate is greater than or equal to the second candidate frame rate and the second candidate frame rate is not equal to the previous target frame rate, the second candidate frame rate is used as the target frame rate.

[0013] In this implementation, different policy priorities are assigned to different frame rate strategies based on actual needs, and then the target frame rate is determined from the frame rates corresponding to the frame rate strategies based on the policy priorities, which can ensure the accuracy of the target frame rate.

[0014] In one possible implementation of the first aspect, determining the first target refresh rate based on the target frame rates of all target applications includes: if there is no touch event and touch enhancement is off, taking the maximum frame rate among the target frame rates corresponding to all target applications as the first target refresh rate; if there is a touch event or touch enhancement is on, taking the refresh rate corresponding to the touch event or touch enhancement as the first target refresh rate.

[0015] In this implementation, when a touch event occurs or the user requests enhanced touch functionality, the target frame rate is determined with the user's touch needs as the primary objective. The target refresh rate is then determined based on this target frame rate, thus ensuring a good user experience. Furthermore, since touch-related requests typically correspond to high refresh rates, even prioritizing touch functionality can meet the needs of the target application.

[0016] In one possible implementation of the first aspect, determining the first target refresh rate based on the target frame rate of all target applications includes: in all refresh rate decision scenarios, if the target application has the highest decision priority, then the first target refresh rate is determined based on the target frame rate of all target applications. In this implementation, when the electronic device does not currently have scenarios with higher decision priority than the target application, such as low battery, virtual disk, or animation effects, the refresh rate is determined based on the target application. That is, if there are other scenarios with higher decision priority than the target application, the refresh rate will be determined first using the strategies corresponding to those other scenarios, thereby ensuring that the determined refresh rate is consistent with the operating state of the electronic device and ensuring the accuracy of the refresh rate.

[0017] In one possible implementation of the first aspect, processor resources are scheduled for the target application according to the target frame rate corresponding to the target application, including: determining the expected frame interval of the target application based on the target frame rate and a preset error frame rate; and scheduling processor resources for the target application when the expected frame interval does not match the historical frame interval of the target application.

[0018] In this implementation, the target frame rate is used to schedule the processor (such as CPU, GPU) capacity / resources of the target application, thereby accurately providing resource supply to the target application and ensuring the performance of the target application.

[0019] In one possible implementation of the first aspect, the refresh rate decision method further includes: generating a frame rate strategy for the target application based on any one or more of the following: system constraint information, the application scenario of the target application, the frame rate scheme requirements, and the frame rate performance of the target application. The frame rate strategy types include constraint strategies and overlay strategies. The system constraint information includes any one or more of the following: temperature-controlled frame rate limiting, non-target scenario restrictions, the maximum frame rate allowed by the target application, and the preset default frame rate of the target application. The scenario information includes any one or more of the following: the application scenario of the target application, split-screen status, and instantaneous power consumption. The frame rate scheme includes any one or more of the following: hardware frame interpolation, software frame interpolation, and frame rate easing. The frame rate performance includes any one or more of the following: the set frame rate of the target application, the real-time frame rate tier, and the self-limiting frame rate of the target application. The real-time frame rate tier is determined based on the rendering rate of the target application, and the self-limiting frame rate is determined based on the real-time frame rate tier.

[0020] In one possible implementation of the first aspect, the self-limiting frame rate of the target application can be determined by calculating the frame interval of the image frames drawn by the target application. Based on this, the refresh rate decision method further includes: acquiring at least two consecutively drawn image frames from the target application, where the number of image frames is equal to a preset number; determining that the target application has an application self-limiting frame when the frame rate corresponding to the target frame interval is less than the real-time frame rate level; wherein the target frame interval is determined based on the frame interval of the image frames; when the target application has an application self-limiting frame, continuously acquiring i sets of image frames, where the number of image frames included in each set is equal to the quotient of the preset number divided by i; where i > 1, and i is a positive integer; and determining the self-limiting frame rate of the target application based on the i frame intervals corresponding to the i sets of image frames and the target frame interval.

[0021] In one possible implementation of the first aspect, the frame rate strategy further includes a high refresh rate triggering strategy, which is used to increase the target frame rate of the target application; the refresh rate decision method further includes: when it is determined that the frame rate of the target application suddenly increases based on the real-time frame rate level of the target application, adding a high refresh rate triggering strategy to the target application; after the added time reaches a preset time or the frame rate of the target application decreases, deleting the added high refresh rate triggering strategy; wherein, the strategy priority of the high refresh rate triggering strategy is lower than the strategy priority of setting the frame rate.

[0022] Therefore, for some target applications that cannot increase the target frame rate and thus the refresh rate by setting the frame rate and scene, a high refresh trigger strategy can be used to provide an opportunity to increase the frame rate in order to meet the high refresh rate requirements of the target application.

[0023] In one possible implementation of the first aspect, the frame rate policy corresponding to the target application is dynamically changed based on the operating state of the electronic device. Determining the target frame rate based on the frame rate policy includes: triggering the determination of the target frame rate when the frame rate policy corresponding to the target application changes; changes include adding, deleting, and updating the frame rate corresponding to the frame rate policy; wherein, during addition or update, the policy pointer moves to the newly added or updated frame rate policy; during deletion, the policy pointer moves to a preset deletion policy, which is added when the frame rate policy for the target application is first deleted. Therefore, when the frame rate policy of the target application changes, a target frame rate decision is triggered, thereby ensuring the accuracy of the target frame rate.

[0024] Secondly, this application provides an electronic device, including: one or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device performs the following steps: running at least one target application in the foreground; for each target application, determining a target frame rate based on a frame rate strategy corresponding to the target application; scheduling processor resources for each target application according to the target frame rate corresponding to the target application; determining a first target refresh rate based on the target frame rates of all target applications, and refreshing the screen of the electronic device according to the first target refresh rate.

[0025] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: if at least one non-target application is running in the foreground and the focused window is a window of a non-target application, a second target refresh rate is determined based on a first target refresh rate and at least one application refresh rate, and the display screen of the electronic device refreshes the screen according to the second target refresh rate; wherein, the second target refresh rate includes at least one of the first target refresh rate and at least one application refresh rate; if there is an application refresh rate greater than the first target refresh rate among the at least one application refresh rates, the second target refresh rate includes application refresh rates greater than the first target refresh rate; if there is an application refresh rate less than the first target refresh rate among the at least one application refresh rates, the second target refresh rate does not include application refresh rates less than the first target refresh rate; if all at least one application refresh rate is less than the first target refresh rate, the second target refresh rate includes only the first target refresh rate; when the second target refresh rate includes only the first target refresh rate, the screen is refreshed according to the first target refresh rate; when the second target refresh rate does not include only the first target refresh rate, a refresh rate is selected from the second target refresh rates based on the application scenario of the non-target application for screen refresh.

[0026] In one possible implementation of the second aspect, the non-target application includes a desktop application, and the application refresh rate includes a first application refresh rate and a second application refresh rate, wherein the first application refresh rate is greater than the second application refresh rate. When the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the second application refresh rate is greater than the first target refresh rate, it is determined that the second target refresh rate includes both the first and second application refresh rates, and the display screen of the electronic device refreshes the screen according to either the first or second application refresh rate based on the application scenario of the non-target application; when the second application refresh rate is less than the first target refresh rate, it is determined that the second target refresh rate includes both the first application refresh rate and the first target refresh rate, and the display screen of the electronic device refreshes the screen according to either the first application refresh rate or the first target refresh rate based on the application scenario of the non-target application; wherein the application scenario corresponding to the first target refresh rate is the same as the application scenario corresponding to the second application refresh rate; when the first target refresh rate is greater than the first application refresh rate, the second target refresh rate is the first target refresh rate, and the display screen of the electronic device refreshes the screen according to the first target refresh rate.

[0027] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: obtaining a target policy from the frame rate policies corresponding to the target application according to a policy pointer; the target policy includes the frame rate policy pointed to by the policy pointer and a frame rate policy with a higher policy priority than the frame rate policy pointed to by the policy pointer; for the restriction policy in the target policy, obtaining the minimum frame rate from the frame rates corresponding to the restriction policy as the first candidate frame rate; for the coverage policy in the target policy, taking the frame rate corresponding to the coverage policy with the highest policy priority as the second candidate frame rate; wherein, when there is no coverage policy in the target policy, the second candidate frame rate is empty; when the first candidate frame rate is less than the second candidate frame rate and the first candidate frame rate is less than the previous target frame rate, the first candidate frame rate is taken as the target frame rate; when the first candidate frame rate is greater than or equal to the second candidate frame rate and the second candidate frame rate is not equal to the previous target frame rate, the second candidate frame rate is taken as the target frame rate.

[0028] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: if there is no touch event and touch enhancement is off, the maximum frame rate among the target frame rates corresponding to all target applications is taken as the first target refresh rate; if there is a touch event or touch enhancement is on, the refresh rate corresponding to the touch event or touch enhancement is taken as the first target refresh rate.

[0029] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: in all refresh rate decision scenarios, if the target application has the highest decision priority, then a first target refresh rate is determined based on the target frame rate of all target applications.

[0030] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: determining the expected frame interval of the target application based on the target frame rate and a preset error frame rate; and scheduling processor resources for the target application when the expected frame interval does not match the historical frame interval of the target application.

[0031] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: Based on system constraint information, the application scenario of the target application, the frame rate scheme requirements, and one or more of the frame rate performance of the target application, a frame rate strategy for the target application is generated accordingly. The frame rate strategy types include constraint strategies and overlay strategies. The system constraint information includes one or more of temperature-controlled frame rate limiting, non-target scenario constraints, the maximum frame rate allowed by the target application, and the preset default frame rate of the target application. The scenario information includes one or more of the application scenario of the target application, split-screen status, and instantaneous power consumption. The frame rate scheme includes one or more of hardware frame interpolation, software frame interpolation, and frame rate easing. The frame rate performance includes one or more of the target application's set frame rate, real-time frame rate tier, and self-limiting frame rate of the target application. The real-time frame rate tier is determined based on the target application's rendering rate, and the self-limiting frame rate is determined based on the real-time frame rate tier.

[0032] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: acquiring at least two consecutively rendered image frames of the target application, the number of image frames being equal to a preset number; determining that the target application has application-limited frames when the frame rate corresponding to the target frame interval is less than the real-time frame rate level; wherein the target frame interval is determined based on the frame interval of the image frames; when the target application has application-limited frames, continuously acquiring i sets of image frames, the number of image frames included in each set being equal to the quotient of the preset number divided by i; i > 1, i is a positive integer; determining the self-limited frame rate of the target application based on the i frame intervals corresponding to the i sets of image frames and the target frame interval.

[0033] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when a sudden increase in the frame rate of the target application is determined based on the real-time frame rate gradation of the target application, a high refresh rate triggering strategy is added to the target application; after the added duration reaches a preset duration or the frame rate of the target application decreases, the added high refresh rate triggering strategy is deleted; wherein, the strategy priority of the high refresh rate triggering strategy is lower than the strategy priority of setting the frame rate. Therefore, for some target applications where the target frame rate cannot be increased by setting the frame rate and scene, and thus the refresh rate cannot be increased, the high refresh rate triggering strategy can provide an opportunity to increase the frame rate to meet the high refresh rate requirements of the target application.

[0034] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the frame rate policy corresponding to the target application changes, a target frame rate is determined based on the frame rate policy corresponding to the target application; the change includes adding, deleting, and updating the frame rate corresponding to the frame rate policy; wherein, during addition or update, the policy pointer moves to the newly added frame rate policy or the updated frame rate policy; during deletion, the policy pointer moves to a preset deletion policy, which is added when the frame rate policy for the target application is deleted for the first time. Thus, when the frame rate policy of the target application changes, a target frame rate decision is triggered, thereby ensuring the accuracy of the target frame rate.

[0035] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor in an electronic device, causes the electronic device to perform a refresh rate decision method as described in the first aspect and any possible implementation thereof.

[0036] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect and any possible implementation thereof. The computer may be the aforementioned electronic device.

[0037] Fifthly, embodiments of this application provide a chip, the chip including a processor, the processor being configured to invoke a computer program in memory to perform a method as described in the first aspect and any possible implementation thereof.

[0038] Understandably, the beneficial effects achieved by the electronic device of any possible implementation of the second aspect, the computer-readable storage medium of the third aspect, the computer program product of the fourth aspect, and the chip of the fifth aspect can be referred to as the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0039] Figure 1This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0040] Figure 2 This application provides a schematic diagram of the structure of a communication system according to an embodiment of the present application.

[0041] Figure 3 A schematic diagram illustrating the principle of a refresh rate decision method provided in an embodiment of this application;

[0042] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0043] Figure 5 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0044] Figure 6 A flowchart illustrating a refresh rate decision method provided in an embodiment of this application;

[0045] Figure 7 A flowchart illustrating a target frame rate decision provided in this application embodiment. Figure 1 ;

[0046] Figure 8 A flowchart illustrating a target frame rate decision provided in this application embodiment. Figure 2 ;

[0047] Figure 9 A schematic diagram of the interface of a touch-enhanced switch provided in an embodiment of this application;

[0048] Figure 10 A schematic diagram illustrating a refresh rate decision method provided in an embodiment of this application;

[0049] Figure 11 A flowchart illustrating a refresh rate decision-making process provided in an embodiment of this application;

[0050] Figure 12 A schematic diagram of an interface for refresh rate decision-making provided in an embodiment of this application;

[0051] Figure 13 This is a structural block diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0052] To facilitate the description and understanding of the solution, the technical terms that may be involved in the embodiments of this application will be explained first.

[0053] Frame rate: Frame rate refers to the frequency at which images appear continuously on a display, that is, the number of frames displayed on the screen per second.

[0054] Refresh rate: Refresh rate refers to the number of times the electron beam scans the image on the screen, that is, the number of times the monitor refreshes the image per second. The unit of refresh rate is Hertz (Hz).

[0055] It should be noted that in this embodiment, frame rate and refresh rate are two different concepts. Generally speaking, frame rate emphasizes the rate at which displayed content is generated, such as the rate at which an application draws and renders image frames. Refresh rate, on the other hand, focuses on how quickly the display refreshes. Simply put, frame rate can be understood as the number of images sent to the display per second, while refresh rate represents the actual speed at which the display shows those images. The refresh rate can be the same as or different from the frame rate of the content to be displayed, but as a hardware specification of the display screen, refresh rate is the upper limit of frame rate performance.

[0056] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., are not necessarily different. Also, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0057] In recent years, with the improvement of hardware performance in electronic devices (such as mobile phones), especially the advancement of processor and display technology, screens supporting high frame rates have gradually become mainstream. For example, current screens can achieve high refresh rates of 90Hz, 120Hz, and even 144Hz. At the same time, to improve user experience, more and more application developers are also optimizing their applications to support high frame rate displays. For example, game developers are optimizing their games to support high frame rate displays, thereby ensuring a smoother visual experience for gamers and increasing their immersion.

[0058] However, a mismatch between the frame rate and the display's refresh rate can easily lead to screen tearing or misalignment, a phenomenon known as image tearing. Furthermore, applications in electronic devices primarily run on the processor, and they rely on processor power / resources to render image frames. Therefore, precise allocation of power / resources by the processor is crucial to ensuring application performance targets are met. Thus, to satisfy application frame rate requirements, prevent screen tearing, and ensure application performance, existing electronic devices employ adaptive settings for frame rate and refresh rate. Additionally, the device will adjust the processor power / resource allocation based on the application's frame rate.

[0059] For applications without a dedicated program engine (hereinafter referred to as non-target applications), application developers generally do not grant users permission to set the frame rate. Therefore, the frame rate of these applications is typically determined based on the display's refresh rate. That is, the frame rate of an application without a dedicated program engine equals the display's refresh rate.

[0060] For applications controlled by a separate program engine (hereinafter referred to as the target application), in order to improve the user experience, application developers generally grant users permission to set the frame rate, providing frame rate adjustment functionality. For example, current game applications (i.e., target applications) all have separate game engine control, so most game applications provide users with a frame rate setting option in the game settings interface. For example, taking a mobile phone as an example... Figure 1 A schematic diagram of a game settings interface is shown.

[0061] refer to Figure 1 The game settings interface includes graphics settings options. When a user selects a graphics settings option in the game settings interface, the electronic device will display the corresponding graphics settings interface, such as... Figure 1 As shown. The image settings interface includes frame rate settings options.

[0062] The phone can respond to a user's tap on the frame rate setting option, displaying the available frame rates. For example... Figure 1 As shown, the settable frame rates include 60, 90, and 120. The phone then responds to the user's click to adjust the frame rate, allowing the game application to complete the frame rate setting. Figure 1 As shown, when a user clicks 120, the game application's frame rate is set to 120.

[0063] Understandable. Figure 1 The interface shown is merely an example of an embodiment of this application. Figure 1 It does not impose any restrictions on the way the game settings interface and game frame rate are set.

[0064] Therefore, for target applications like games, users can adjust the frame rate according to their needs. To meet user requirements, traditional electronic devices typically use the target application's set frame rate or its actual frame rate as the target frame rate. The electronic device then determines the refresh rate based on the determined target frame rate, and adjusts processor capabilities / resources accordingly.

[0065] However, because high refresh rates mean high power consumption, simply adjusting the refresh rate and allocating processor resources according to the target application's set frame rate or actual frame rate may guarantee the application's performance, but it compromises the device's power consumption. This results in an inability to balance performance and power consumption, leading to battery anxiety. This battery anxiety is particularly pronounced when running applications with high refresh rates, such as games.

[0066] Therefore, in order to solve the problem of range anxiety, there is another decision-making solution for the above-mentioned target applications.

[0067] For example, taking a game application as the target application, Figure 2 A block diagram illustrating the principle of a traditional decision-making scheme is shown below. The following section, in conjunction with... Figure 2 This paper explains the traditional refresh rate decision-making scheme.

[0068] In traditional refresh rate decision-making schemes, if an electronic device is currently running a game application in the foreground, then, if Figure 2 As shown in Figure (1), the game scene refresh rate decision module in the electronic device first determines the refresh rate required by the game application based on system and game information. Then, the electronic device determines a target frame rate based on the determined refresh rate. Next, the game scene refresh rate decision module sends the determined target frame rate to the scheduling service. The scheduling service then schedules processor capabilities / resources based on the sent target frame rate to ensure the supply of processor capabilities / resources to the game application. In addition, the determined refresh rate is also sent to the display screen, which refreshes the screen according to the determined refresh rate.

[0069] Furthermore, it's understandable that because the game scene refresh rate decision module considers game-related information when making refresh rate decisions, the determined refresh rate generally meets the frame rate requirements of the game application. Moreover, in actual operation, the application's rendering speed can be adjusted accordingly based on the refresh rate; therefore, the game scene refresh rate decision module may not actually need to send a target frame rate to the game application. Of course, based on actual needs, the determined target frame rate can also be sent to the game application, allowing the game application to accurately render image frames according to the sent target frame rate. This application embodiment does not impose any limitations on this.

[0070] However, Figure 2 The problem with the decision-making scheme shown in (1) is that, in addition to considering the frame rate requirements of target applications such as game applications, there are some scenarios with higher decision priority in the current refresh rate decision.

[0071] For example, refresh rate decisions made in scenarios such as low battery, virtual screens, and animated effects have a higher priority than those based on the frame rate requirements of gaming applications. In other words, besides target applications like games triggering refresh rate decisions on electronic devices, scenarios such as low battery, virtual screens, and animated effects also trigger refresh rate decisions. Furthermore, the decision priority in these scenarios is higher than that for gaming applications.

[0072] like Figure 2 As shown in Figure (2), taking the low-power scenario as an example, if an electronic device is simultaneously in a low-power scenario and a gaming scenario, the low-power scenario should be given priority. Therefore, the electronic device will determine the refresh rate of the display screen based on the refresh rate strategy corresponding to the low-power scenario. In other words, even if the electronic device is currently in a gaming scenario, because the decision priority of the low-power scenario is higher than that of the gaming scenario, only the low-power scenario refresh rate decision module in the electronic device will be triggered to decide the refresh rate according to the corresponding refresh rate strategy.

[0073] In other words, the refresh rate decision at this point does not take into account the frame rate requirements of the game application. As a result, not only may the decided refresh rate fail to meet the frame rate requirements of the game application, but also, due to the coupling relationship between frame rate and refresh rate—that is, the frame rate needs to be determined based on the refresh rate determined by the game scene decision module—the scheduling service may be unable to receive the target frame rate, thus failing to guarantee the supply of capabilities / resources to the game application.

[0074] Furthermore, in high-concurrency application scenarios, such as electronic devices displaying multiple game applications simultaneously in the foreground via floating windows or split-screen, because... Figure 2The decision scheme shown in (1) is to first decide the refresh rate and then send the target frame rate to the scheduling service for processor capacity / resource scheduling. This means that all target applications are based on the same target frame rate to obtain resource supply. Therefore, the multiple target applications displayed in the foreground may be interfered with each other, which may lead to applications in the foreground that cannot meet the performance requirements, thereby reducing the application performance and reducing the user experience in scenarios such as floating windows and split screens.

[0075] Based on this, in order to ensure the supply of capabilities / resources for the target application, and to avoid mutual interference among multiple target applications in the foreground under high-concurrency scenarios, and to meet the performance requirements of all target applications in the foreground as much as possible, thus ensuring the performance of the target application, this application provides a refresh rate decision method. The refresh rate decision method provided in this application is applied to electronic devices.

[0076] To facilitate the description and understanding of the solution, the following embodiments of this application will mainly be described using a game application as an example.

[0077] Figure 3 A schematic diagram illustrating the refresh rate decision method provided in an embodiment of this application is shown.

[0078] refer to Figure 3 In embodiments of this application (1) and (2), when multiple game applications are running in the foreground of an electronic device, the electronic device first determines a target frame rate for each game application based on system limitation information, other frame rate scheme requirements, scene information and frame rate performance of the game application. That is, if n game applications are running and displayed simultaneously in the foreground through floating windows, split screens, etc., the electronic device can determine n target frame rates for each of these n game applications, and these n game applications correspond one-to-one with these n target frame rates.

[0079] Then, if the scenario with the highest decision priority is the game application, the electronic device can make a refresh rate decision based on these n target frame rates, determine the target refresh rate, and refresh the screen of the electronic device according to the determined target refresh rate. Simultaneously, regardless of whether the game application has the highest decision priority, since the target frame rate for the game application has been determined, the electronic device can send these n target frame rates to the scheduling service. The scheduling service then allocates processor power / resources to the corresponding n game applications based on these n target frame rates, thereby satisfying the resource supply for each game application.

[0080] In other words, if there are other scenarios with higher decision priority than the game scenario, such as a low battery scenario, then although the electronic device cannot make a refresh rate decision based on these n target frame rates, the target frame rates have already been obtained in this embodiment of the application. Unlike traditional methods that rely on refresh rates to determine the target frame rate, the electronic device can still send these n target frame rates to the scheduling service. The scheduling service then schedules the processor's capabilities / resources for the corresponding n game applications based on these n target frame rates.

[0081] Therefore, in this embodiment of the application, because the frame rate and refresh rate are decoupled, that is, the target frame rate is not determined by relying on the refresh rate, but the target frame rate of the game application is decided first based on various information, and then the target refresh rate is decided based on the target frame rate. This isolates the impact of some high-priority 2D non-game scenarios (such as low battery, screen recording, animation, etc.) on the target frame rate decision of the game application, thereby ensuring the resource supply on the game application side.

[0082] Meanwhile, in high-concurrency scenarios, because the frame rate and refresh rate are decoupled in this application embodiment, this application embodiment can also make target frame rate decisions for each game application separately, thereby scheduling resources according to the target frame rate of different game applications, thereby avoiding mutual interference between game applications and meeting the performance requirements of all game applications as much as possible.

[0083] The aforementioned electronic devices may include at least one of the following: mobile phones, foldable electronic devices, tablet computers, desktop computers, laptop computers, handheld computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, or smart city devices. This application does not impose any specific limitations on the type of electronic device described.

[0084] For example, Figure 4 A schematic diagram of the structure of an electronic device is shown.

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

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

[0087] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors. Processor 110 can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0088] Specifically, in this embodiment of the application, when multiple target applications (such as game applications) are running in the foreground, the processor 110 can make a target frame rate decision based on each target application separately. Then, resource scheduling is performed accordingly based on the target frame rates corresponding to different target applications to avoid mutual interference and ensure that the performance requirements of each target application are met. At the same time, in the current scenario, if the target application has the highest decision priority, the processor 110 can also determine the target refresh rate based on the target frame rates of these multiple target applications, so that the display screen refreshes the image according to the determined target refresh rate.

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

[0090] In some embodiments, the processor 110 may include one or more interfaces. These interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc. The processor 110 can connect to modules such as touch sensors, audio modules, wireless communication modules, displays, and camera modules through at least one of these interfaces.

[0091] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0092] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, it can save music, video, and other files to the external memory card, or transfer music, video, and other files from the electronic device to the external memory card.

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

[0094] USB connector 130 is a USB standard compliant interface used to connect electronic device 100 and peripheral devices, specifically a Mini USB connector, Micro USB connector, USB Type-C connector, etc. Charging management module 140 receives charging input from the charger. Power management module 141 connects to battery 142, and charging management module 140 connects to processor 110.

[0095] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

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

[0097] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or more display screens 194.

[0098] Electronic device 100 can realize camera function through camera module 193, ISP, video codec, GPU, display screen 194, application processor AP, neural network processor NPU, etc.

[0099] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0100] In some embodiments, the software system of the electronic device 100 may adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. The following embodiments of this application will use a layered architecture of Android as an example. TM Taking the system as an example, the software structure of electronic device 100 is illustrated. It is understandable that a layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces.

[0101] For example, Figure 5 A software architecture block diagram of an electronic device is shown.

[0102] refer to Figure 5 In some embodiments, Android can be TM The system is divided into five layers, from top to bottom: application layer, application framework layer, native service layer, hardware abstraction layer (HAL), and kernel layer.

[0103] The application layer can include a series of application packages. For example... Figure 5As shown, the application package may include games. Games include puzzle games, competitive games, etc., and this application embodiment does not impose any limitations on them.

[0104] In other embodiments, based on actual needs, the application package may also include applications such as gallery, calendar, map, WLAN, music, SMS, call, navigation, Bluetooth, and video. This application embodiment does not impose any limitations on this.

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

[0106] like Figure 5 As shown, the application framework layer includes a frame rate limiting service and a game service. The frame rate limiting service provides frame rate limiting, such as temperature-controlled frame rate limiting. That is, it limits the maximum frame rate of the game application based on the temperature of the electronic device. For example, when the electronic device is severely overheated, the frame rate limiting service can send a corresponding frame rate limit to the AGP service to control the frame rate reduction. When the temperature of the electronic device drops and it is no longer overheating, the frame rate limiting service can lift the temperature-controlled frame rate limit, allowing the frame rate to be increased again, thereby avoiding further overheating. It is understood that, in addition to temperature-controlled frame rate limiting, other conditions can be set in the frame rate limiting service based on actual needs; this embodiment does not impose any limitations on this.

[0107] A game service is a service used to provide communication with game applications. By communicating with game applications, the game service can obtain the game application's set frame rate. The set frame rate can be found in [reference needed]. Figure 1 As shown. Furthermore, the game service can also acquire different application scenarios for the game application. These different application scenarios for the game application will be referred to as game scenarios below.

[0108] For example, game scenarios can be divided into critical game scenarios and non-critical game scenarios. Critical game scenarios can include game scenarios with high frame rate requirements, such as in-game scenes. Non-critical game scenarios can include game scenarios with low frame rate requirements, such as game loading scenes, character death scenes, and other non-in-game scenes.

[0109] In other embodiments, the application framework layer may further include a window manager, activity manager, input manager, resource manager, notification manager, view system, content provider, etc. The window manager provides a window manager service (WMS), which can be used for window management, window animation management, surface management, and as a relay station for the input system. The content provider stores and retrieves data, making this data accessible to applications. This data may include video, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0110] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include a view for displaying text and a view for displaying images. The resource manager provides applications with various resources, such as localized strings, icons, images, layout files, video files, and so on.

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

[0112] The Activity Manager provides the Activity Manager Service (AMS), which manages and schedules system components (such as activities, services, content providers, and broadcast receivers) and application processes. The Input Manager provides the Input Manager Service (IMS), which manages system input, such as touchscreen input, keypad input, and sensor input. IMS retrieves events from input device nodes and, through interaction with the Workflow Management System (WMS), distributes these events to appropriate windows.

[0113] The native service layer includes surface flinger (SF) service and advanced graphics processing (AGP) service.

[0114] The SF service is used for layer compositing, such as compositing image frames (i.e., layers) rendered for game applications to generate a game interface including the corresponding screen frames, which is then transmitted to the display screen for display. In this embodiment, the SF service also includes a frame rate information filtering function. Specifically, the SF service can filter out the image frames of the main scene of the target application (i.e., the main layer of the game application), and then send the timestamp of the main layer to the AGP service, so that the AGP service can calculate the real-time frame rate level of the game application based on the timestamp.

[0115] The AGP service includes a real-time frame rate tier calculation module, a self-limiting frame rate recognition module, a target frame rate decision module, and a refresh rate decision module.

[0116] In this embodiment, the game real-time frame rate tier calculation module is used to calculate the real-time frame rate tier of the game application. The real-time frame rate tier can be understood as the actual frame rate at which the game application operates. It is understood that, if the game application includes a set frame rate, the real-time frame rate tier may be slightly higher or lower than the set frame rate, or the real-time frame rate may be equal to the set frame rate. The application's real-time frame rate tier can be calculated based on the timestamp sent by SF.

[0117] The game self-limiting frame rate identification module is used to identify the frame rate of certain applications with application-specific self-limiting frames. For example, actual testing may show that although the real-time frame rate calculation for a game application is set at 60fps, the actual frame rate may be stabilized at 52fps due to application-specific self-limiting frames. Therefore, to save device power consumption, the frame rate corresponding to application-specific self-limiting frames can be considered when making target refresh rate decisions.

[0118] The game target frame rate decision module is used to determine the target frame rate of the game application. The game refresh rate decision module is used to determine the game refresh rate (i.e., the first target refresh rate) based on the game application's target frame rate.

[0119] The Hardware Abstraction Layer (HAL) runs in user space, encapsulates kernel-level drivers, and provides calling interfaces to higher layers. For example... Figure 5 As shown, the Hardware Abstraction Layer (HAL) can include a scheduling service and a display HAL. The scheduling service receives the target frame rate from the AGP service to schedule processor capabilities / resources for the game application. The display HAL receives the refresh rate from the AGP service to invoke the display driver and control the display screen to operate according to the decided refresh rate.

[0120] In other embodiments, the hardware abstraction layer may also include audio HAL, camera HAL, Bluetooth HAL, etc., based on actual needs. This application does not limit this in any way.

[0121] The kernel layer is the layer between hardware and software. For example... Figure 5 As shown in the embodiments of this application, the kernel layer includes at least a display driver. In other embodiments, based on actual needs, the kernel layer may also include an audio driver, a camera driver, a Bluetooth driver, etc., and this application does not impose any limitations on this.

[0122] The refresh rate decision method proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that the refresh rate decision method in the following embodiments can be implemented in the electronic device 100 having the above-described hardware structure.

[0123] Combination Figure 5 The software structure shown is as follows: Figure 6 A flowchart of a refresh rate decision method is shown, including steps S1-S9.

[0124] S1, the game application responds to user input and starts.

[0125] S2, the game application sends image frames to the SF service.

[0126] After the game application starts, it draws and renders an image frame and sends that image frame to SF.

[0127] S3 and SF services filter frame rate information.

[0128] After receiving image frames sent by the game application, the SF service synthesizes the image frames to generate a corresponding game interface, which is then transmitted to the display screen for display. Simultaneously, in this embodiment, the SF service also needs to filter frame rate information based on the image frames to facilitate the calculation of the game application's real-time frame rate level.

[0129] Specifically, the SF service first filters out image frames related to the main scene of the game application based on the number of drawing instructions corresponding to each image frame sent by the game application. Then, the SF service extracts the timestamp of each of the filtered main scene image frames and sends the timestamp to the game real-time frame rate tier calculation module in the AGP service, which then calculates the real-time frame rate tier.

[0130] Understandably, each image frame has a timestamp, which represents the moment when rendering or compositing is complete. This allows electronic devices to calculate and determine the actual rendering rate of a game application using these timestamps, thus obtaining the game's real-time frame rate tier. For example, real-time frame rate tiers could be 30, 60, 90, etc.

[0131] In addition, in high-concurrency scenarios where multiple game applications are running in the foreground, the SF service needs to perform image frame filtering and timestamp recording for each game application separately. This makes it easier to obtain the real-time frame rate level corresponding to each game application, which in turn facilitates the determination of the corresponding target frame rate for each game application in the future.

[0132] S4, the game frame rate real-time tier calculation module calculates the real-time frame rate tier based on the timestamp.

[0133] After obtaining the timestamps transmitted by the SF service, the game frame rate real-time tier calculation module can calculate the real-time frame rate tier of the game application based on the timestamps. For example, for game A, if the game frame rate real-time tier calculation module has received and stored 60 timestamps sent by the SF service in the past second, then the real-time frame rate tier of game A can be determined to be 60fps. As another example, if the game frame rate real-time tier calculation module has received 120 timestamps related to game A in the past second, then the real-time frame rate tier of game A can be determined to be 120fps.

[0134] S5, the game self-limiting frame rate recognition module obtains the real-time frame rate level to perform application self-limiting frame rate recognition and determine the self-limiting frame rate.

[0135] The game's self-limiting frame rate (WFR) identification module first acquires a preset number of image frames rendered by the game application, for example, 200 frames. Then, it determines the game application's frame rate based on the frame intervals of these 200 frames. If the frame rate determined by the WFR identification module is lower than the real-time frame rate threshold, the game application is identified as having an application-specific WFR. To accurately determine the WFR rate, the preset number of frames can be divided into i equal parts, for example, 10 equal parts. This involves acquiring 10 consecutive sets of 20 frames each, forming a set of 10 image frames. Finally, the frame rate is determined based on the frame intervals of these 20 frames. Furthermore, if the frame rates of these 10 image frame sets are consistently within a certain range compared to the frame rate of the 200 frames, the frame rate of the 200 frames can be taken as the game application's WFR rate.

[0136] S6, the game target frame rate decision module obtains the set frame rate and game scene.

[0137] like Figure 6As shown, the game service communicates with the game application to obtain the application's frame rate settings and game scene. Then, the game service sends this information to the AGP service's target frame rate decision module. Understandably, in practical applications, if the game application does not have access to read this information, the game service cannot communicate with it to obtain the frame rate settings and game scene.

[0138] S7, the game target frame rate decision module determines the target frame rate of the game application based on the frame rate strategy corresponding to the game application.

[0139] In this embodiment, the frame rate strategy is generated based on system limitation information, game scenario, frame rate scheme requirements, and the frame rate performance of the game application. In other words, system limitation information, game scenario, frame rate scheme, and frame rate performance are the data required for the target frame rate decision in this embodiment. Specifically, in this embodiment, making a target frame rate decision for a game application requires considering four main factors simultaneously: the system, the game application's application scenario, the requirements of other frame rate schemes, and the application's own frame rate requirements.

[0140] System limitation information refers to frame rate policies configured based on system state requirements. System state can be obtained through system instrumentation. This system limitation information includes an AGP configuration file, which contains the maximum frame rate allowed for the game application, i.e., the game application's `maxfps`. System limitation information also includes temperature-controlled frame rate limiting, the game application's default frame rate, 2D scene limitations, and a frame rate limiting service configuration file.

[0141] In this embodiment, the frame rate limiting service configuration file also includes other frame rate limiting conditions besides temperature-controlled frame rate limiting. These conditions can be set according to actual needs, and no limitations are imposed. The default frame rate of the aforementioned game application is the most common frame rate in most games. 2D scene limiting refers to frame rate limiting in non-game scenarios (i.e., non-target scenarios) such as low battery or screen recording. These conditions can be set according to actual needs, and no limitations are imposed in this embodiment.

[0142] The game scene refers to the frame rate strategy configured according to different application scenarios of the game application. In this embodiment, in order to ensure application performance while reducing power consumption and slowing down device overheating, different frame rates can be applied based on different game scenarios. That is, the corresponding frame rate is pre-configured according to different game scenarios. Then, when deciding on the target frame rate, the application scenario of the game application can be taken into account. For example, in intense competitive game scenarios, smooth performance must be ensured, so a high frame rate game performance should be provided as much as possible according to user expectations in this scenario. In non-critical game scenarios, such as game lobby scenarios or scenarios where game characters wait to revive after death, the frame rate can be appropriately reduced. This reduces power consumption and slows down device overheating while ensuring the minimum performance level.

[0143] Frame rate schemes refer to other frame rate schemes designed for game applications, such as software motion estimation and motion compensation (SMEMC), hardware motion estimation and motion compensation (MEMC), and frame rate gradation. Each of these schemes has a target frame rate. Therefore, the requirements of the frame rate scheme must be considered when deciding on the target frame rate.

[0144] The frame rate performance of a game application refers to the frame rate displayed by the game application itself, i.e., the frame rate requirement of the game application. In this embodiment, the frame rate performance considers not only the set frame rate of the game application but also its real-time frame rate tier. Furthermore, if the game application has an application-defined frame rate limit, the limit frame rate can also be considered. The real-time frame rate tier and the limit frame rate can be obtained by calculating the real-time frame rate tier and the limit frame rate, as described in steps S3-S4 above. In other words, when deciding on the target frame rate of a game application, the frame rate performance considered includes any one or more of the game application's set frame rate, real-time frame rate tier, and limit frame rate.

[0145] In other embodiments, for game applications that do not have open communication permissions, electronic devices cannot obtain the corresponding game scenes through game services, and therefore cannot control the frame rate increase or decrease based on frame rate settings and game scenes. Therefore, for these game applications, embodiments of this application also provide a high refresh rate triggering strategy.

[0146] A high refresh rate trigger strategy is generated when the frame rate of a game application suddenly increases. Whether the frame rate has suddenly increased can be determined by calculating the real-time frame rate threshold. For example, if the real-time frame rate threshold of a game application is 20fps, it can be determined that the game application is currently in a loading scene. When the real-time frame rate threshold of the game application suddenly increases to 90 / 120fps, it can be determined that loading is complete and the game has entered the scene. This moment of frame rate increase is the high refresh rate trigger point for the game application. To provide sufficient capacity / resources, a high refresh rate trigger strategy can be generated for this game application. The frame rate corresponding to the high refresh rate trigger strategy is generally a high frame rate, such as 90 or 120. Therefore, by adding a high refresh rate trigger strategy at the high refresh rate trigger point, when deciding the target refresh rate for this game application, if there are no other frame rate strategies with higher priority, the target frame rate can be increased accordingly under the influence of the high refresh rate trigger strategy, thereby meeting the application's frame rate requirements.

[0147] However, it's important to note that the high refresh rate trigger strategy has a lower priority than the frame rate setting strategy. In other words, if the set frame rate is available, the target frame rate will be determined based on that setting.

[0148] For example, Figure 7 and Figure 8 A flowchart illustrating a target frame rate decision is shown below. Figure 7 and Figure 8 The process of determining the target frame rate is explained in detail.

[0149] refer to Figure 7 and Figure 8 The inputs for the target frame rate decision include four main data components: system limitations, game scene, frame rate methodology, and frame rate performance. Furthermore, each of these four data components contains multiple pieces of information. For example... Figure 7 and Figure 8 As shown, system limitations include temperature-controlled frame rate limiting, default frame rate for game applications, 2D scene limitations, frame rate limiting service configuration files, and AGP configuration files. Game scenes include non-in-game scenes, character death scenes, split-screen gameplay, and instantaneous power consumption. Frame rate solutions include SMEMC, MEMC, and frame rate shaving. Frame rate performance includes set frame rate, real-time frame rate tiers, self-limiting frame rate, and high refresh rate trigger points.

[0150] Instantaneous power consumption refers to the frame rate reduction required to lower power consumption when the instantaneous power consumption of a game application exceeds a threshold. Whether the instantaneous power consumption of a game application exceeds the threshold can be determined by the electronic device's battery status.

[0151] Understandable. Figure 7 and Figure 8The input items shown are merely one example in the embodiments of this application. Based on different needs and applications, the input items may be increased or decreased accordingly, and the embodiments of this application do not impose any limitations on this.

[0152] That is, the electronic device can set different input items for different target applications, and the input items for each target application can be the same or different. In a specific embodiment, when the electronic device includes multiple game applications, the electronic device can set different input items for each game application individually. The input items corresponding to each game application can be the same or different. Furthermore, the input items corresponding to different game applications can be repeated or not.

[0153] In this embodiment, the electronic device can establish a separate frame rate decision pool for each game application, and the input items mentioned above are all abstracted as a frame rate strategy. When the operating state of the electronic device changes, causing the frame rate strategy for determining the target frame rate of the game application to need to be changed accordingly, the electronic device adds, modifies, or deletes items from the frame rate decision pool corresponding to the game application. That is, based on the operating state of the electronic device, it dynamically adds frame rate strategies, deletes frame rate strategies, and updates the frame rate corresponding to the frame rate strategy for the target application.

[0154] For example, suppose both game A and game B have temperature control for their corresponding input items. Assume that when the temperature of the electronic device exceeds A degrees Celsius, the refresh rate needs to be reduced to lower the temperature and save power. Then, if the temperature control strategy limits the maximum frame rate to 70, the "Temperature Control -70" strategy needs to be added to the frame rate decision pools of both game A and game B when the temperature is above A degrees Celsius. In other words, game A and game B now have a new frame rate strategy, "Temperature Control -70". Subsequently, when the temperature of the electronic device drops below A degrees Celsius, the frame rate limitation imposed by the "Temperature Control -70" strategy can be removed, meaning the "Temperature Control -70" strategy is deleted from the frame rate decision pools of game A and game B.

[0155] Furthermore, this application embodiment follows the principle of system limitations > game scenario > business requirements > frame rate performance, assigning different priorities to different frame rate strategies in the frame rate decision pool, with lower-priority strategies being influenced and constrained by higher-priority strategies. For example... Figure 7 and Figure 8 As shown, the frame rate strategies entering the frame rate decision pool are sorted from high to low priority.

[0156] For ease of distinction, the priority of the frame rate strategy is referred to as the strategy priority in this application embodiment.

[0157] In this application embodiment, the frame rate strategy in the frame rate decision pool is mainly divided into two types. One is to execute a high-priority overriding action, the strategy type of which is named the overriding strategy: a high-priority strategy can directly overridden a low-priority strategy. The other is to execute a capping limit action, the strategy type of which is named the limit strategy: low-priority strategies are not allowed to exceed the frame rate limit of the high-priority limit strategy. For example, Figure 7 and Figure 8 As shown, the AGP configuration file, temperature-controlled frame rate limiting, and maximum screen refresh rate are the three frame rate limiting strategies. SMEC, on the other hand, includes frame rate easing, frame rate setting, real-time frame rate tier, default frame rate, and deletion strategies, which are the overriding strategies.

[0158] In some embodiments, where an electronic device includes multiple game applications, the device needs to establish a separate frame rate decision pool for each game application. Each game application's frame rate decision pool includes strategies considered for determining the target frame rate for that game application. Therefore, the frame rate strategies in the frame rate decision pools for different game applications can be the same or different.

[0159] Every action in the frame rate decision pool triggers a target frame rate decision. For example, adding a frame rate policy to the frame rate decision pool triggers a target frame rate decision. Figure 7 As shown, the current strategy was originally "remove frame rate -60". However, because the game application's set frame rate is read at this time, the strategy "set frame rate -80" will be added to the frame rate decision pool. Therefore, because of the new strategy, a target frame rate decision will be triggered.

[0160] In one specific implementation, since all frame rate strategies are assigned a priority, when a new strategy is added, to improve decision-making efficiency and speed up the process, only frame rate strategies with a higher priority than the newly added strategy can be considered. Therefore, a strategy pointer can be added to the implementation, pointing to the latest changed frame rate strategy. Then, based on the strategy pointer, a subset of frame rate strategies from the game application are selected as the target strategy for the target frame rate decision.

[0161] like Figure 7 As shown, after adding the new policy "Set Frame Rate -80", the policy pointer moves from its original position of "Remove Frame Rate -60" to "Set Frame Rate -80". That is, the policy pointer moves from position ① to position ②. Therefore, when making the target frame rate decision, only the frame rate policies (i.e., the target policies) listed before "Set Frame Rate -80" need to be considered. In other words, only frame rate policies with a higher priority than "Set Frame Rate -80" participate in the target frame rate decision.

[0162] For example, removing a strategy from the frame rate decision pool will also trigger a target frame rate decision. Figure 8 As shown, because the device temperature has decreased, the additional frame rate limit of 70 is no longer necessary, so the temperature-controlled frame rate policy can be removed. Therefore, the policy "Temperature Control -70" is deleted. At this point, because the policy has changed, a target frame rate decision will also be triggered.

[0163] In one specific implementation, when a policy pointer is set, because only a policy is deleted, after deleting the policy "Temperature Control -70", the pointer that originally pointed to the policy "Temperature Control -70" will remain at its original position. Thus, when making the target frame rate decision, only policies with higher priority before that position will be considered. However, considering that the target frame rate decision triggered by policy deletion should consider all existing frame rate policies, meaning that deleting a policy cannot, like adding a policy, only select frame rate policies with higher priority than the added policy for decision-making. Therefore, as... Figure 8 As shown, in the scenario of policy deletion, after deleting the policy, you can simultaneously add a deletion policy with the lowest priority, such as... Figure 8 The "Delete Policy - 60" is shown. Subsequently, the policy pointer will move from position ① to position ②, pointing to the newly added delete policy. This also means that when making target frame rate decisions, all frame rate policies with higher policy priority than the delete policy must be considered.

[0164] It should be noted that, Figure 8 The "Delete Policy - 60" shown is essentially an empty message; its main purpose is to facilitate moving the policy pointer. Therefore, the 60 corresponding to "Delete Policy - 60" is also an invalid frame rate value, meaning that 60 can also be replaced with values ​​such as 1, 2, 3, 4, etc.

[0165] In another embodiment, after performing a deletion action, besides moving the policy pointer by adding a preset deletion policy, the policy pointer can also be moved to the last policy after the deletion action is completed, that is, moved to the frame rate policy with the lowest policy priority. It is understandable that if the addition / deletion method is used, the deletion policy is added to the frame rate decision pool during the first deletion action and will remain in the frame rate decision pool thereafter. Therefore, subsequent movements are equivalent to moving the pointer to the last deletion policy.

[0166] When a frame rate strategy change triggers a target frame rate decision, the game's target frame rate decision module first needs to determine a candidate frame rate based on the two different types of strategies. Then, the game's target frame rate decision module selects one of these two candidate frame rates as the target frame rate.

[0167] For ease of distinction, the two candidate frame rates determined below will be referred to as the coverage frame rate and the limit frame rate, respectively, namely the first candidate frame rate and the second candidate frame rate as referred to in the embodiments of this application.

[0168] Specifically, firstly, regarding the cover strategy, the system iteratively finds the cover strategy with the highest priority in the frame rate decision pool, and uses the frame rate corresponding to this cover strategy as a candidate frame rate. For example, Figure 7 In the cover strategies shown, the frame rate strategy with the highest priority is SMEMC, and the frame rate corresponding to SMECE is 120. Figure 7 The coverage frame rate (coverfps) is 120. And, as... Figure 8 In the cover strategy shown, the frame rate strategy with the highest priority is frame rate easing, and the frame rate easing corresponds to a frame rate of 80. Figure 8 The coverfps is 80.

[0169] For the limit strategy, the system iteratively finds the limit strategy with the lowest frame rate in the frame rate decision pool and uses this lowest frame rate as a candidate frame rate. For example, Figure 7 The strategy with the lowest frame rate shown in the limit strategy is temperature control, so Figure 7 The frame rate limit (limitfps) is 70. And, as... Figure 8 As shown, because the temperature control strategy has been removed, Figure 8 The limit strategy shown has the lowest frame rate of 90 corresponding to the AGP configuration file, so... Figure 8 The limitfps is 90.

[0170] Then, because the limiting policy is a capping policy, the frame rate limit is a capped value that cannot be exceeded. Therefore, a decision needs to be made between coverfps and limitfps to determine the target frame rate. That is, the two candidate frame rates are compared to determine a target frame rate. For example, as shown below... Figure 7 and Figure 8 As shown, when the limit frame rate is less than the overlay frame rate, the target frame rate is determined to be equal to the limit frame rate. Conversely, when the limit frame rate is greater than the overlay frame rate, the target frame rate is determined to be equal to the overlay frame rate.

[0171] refer to Figure 7 Because the frame rate limit of 70 is less than the overlay frame rate of 120, the condition is satisfied that the frame rate limit is less than the overlay frame rate. Therefore, in Figure 7 From this, we can determine that the target frame rate equals the limit frame rate, and the target frame rate is 70. The reference... Figure 8 Because the frame rate limit of 90 is greater than the overlay frame rate of 80, the condition that the frame rate limit is greater than the overlay frame rate is met. Therefore, in Figure 8It can be determined that the target frame rate equals the coverage frame rate, and the target frame rate is 80.

[0172] Next, after deciding between coverfps and limitfps, it is necessary to further determine whether the determined target frame rate is valid. Only valid target frame rates can be stored and distributed. Specifically, for the cover strategy, which in this embodiment represents a frame rate change, it is only necessary to determine whether the target frame rate is different from the previous one to consider the determined target frame rate valid. For the limit strategy, which in this embodiment represents a frame rate cap, it must be lower than the previous target frame rate to be considered valid.

[0173] For example, such as Figure 7 As shown, the previous target frame rate was 90, which is greater than the current target frame rate of 70. Furthermore, the target frame rate of 70 corresponds to a frame rate limit, meaning the current target frame rate uses a limit policy. Therefore, its validity depends on whether it is lower than the previous target frame rate. Since 70 is less than 90, it is lower than the previous target frame rate, and thus the target frame rate of 70 is valid. This valid target frame rate is then further distributed to the scheduling service and the game refresh rate decision module.

[0174] For example, such as Figure 8 As shown, the previous target frame rate was 70, which is less than the current target frame rate of 80. Furthermore, the target frame rate of 80 corresponds to an overlay frame rate, meaning the current target frame rate uses an overlay strategy. Therefore, its validity depends on whether it differs from the previous target frame rate. Since 70 and 80 are different, the target frame rate of 80 is valid. For a valid target frame rate, it is further distributed to the scheduling service and the game refresh rate decision module.

[0175] Understandably, for invalid target frame rates, this application embodiment will not send them to the scheduling service and the game refresh rate decision module. That is, as... Figure 7 and Figure 8 As shown, when the target frame rate is determined to be no less than the previous target frame rate, or when the target frame rate is determined to be equal to the previous target frame rate, the current target frame rate decision is deemed invalid, and the current decision process ends, awaiting a policy change for the next decision. It should be noted that for the initial target frame rate decision, since the previous target frame rate was empty, the initial target frame rate decision does not require further validation and is directly determined to be valid.

[0176] It should be noted that, because this application embodiment can select only a subset of frame rate strategies with higher policy priority to participate in the target frame rate decision based on the policy pointer (i.e., each target frame rate decision only considers frame rate strategies with higher policy priority than the current frame rate strategy), when the policy pointer points to the limit policy, it indicates that the cover policy will not be considered at this time. Therefore, the cover frame rate may be empty, meaning the second candidate frame rate will be empty. When the cover frame rate is empty, the comparison process between the cover frame rate and the limit frame rate can be skipped. However, it is understandable that, because it is empty, even if a comparison is made, the limit frame rate will be greater than the cover frame rate.

[0177] as well as, Figure 7 and Figure 8 The frame rates corresponding to the various frame rate strategies, such as 70 in "Temperature Control-70" and 90 in "AGP Configuration-90", are merely examples of embodiments of this application and do not constitute any limitation on the frame rates corresponding to the various frame rate strategies. They can be adjusted according to actual needs, and this application embodiment does not impose any limitations on them.

[0178] S8, the game refresh rate decision module determines the target refresh rate based on the target frame rate.

[0179] After receiving the target frame rate from the game target frame rate decision module, the game refresh rate decision module can make a refresh rate decision based on the target frame rate to obtain the target refresh rate. That is, a suitable refresh rate is selected as the target refresh rate to adapt to the game application's target frame rate. In a specific embodiment, if there is only one target frame rate, then to meet the frame rate requirements of the game application, the target refresh rate can be determined based on this single target frame rate; for example, target refresh rate = target frame rate.

[0180] In another specific embodiment, if multiple target frame rates are issued, meaning multiple game applications are currently running in the foreground, then the target refresh rate needs to be determined based on these multiple target frame rates in order to meet the frame rate requirements of multiple game applications. For example, the target refresh rate = the largest target frame rate.

[0181] In some embodiments, for games that rely heavily on touch, such as fighting games and competitive games, electronic devices need to increase the refresh rate during touch input in order to improve responsiveness and ensure the speed and smoothness of user touch response.

[0182] Furthermore, to ensure a better gaming experience, existing electronic devices also offer touch enhancement switches for gaming applications. When a user turns on the touch enhancement switch, the electronic device needs to enhance touch sensitivity and improve responsiveness, which also requires a higher refresh rate.

[0183] For example, taking a mobile phone as an example, Figure 9A schematic diagram of the interface of a touch-enhanced switch is shown.

[0184] like Figure 9 As shown, the game settings interface 901 includes a touch enhancement control option 902, which includes a switch 903. The phone responds to the user clicking the switch 903 to turn touch enhancement on or off. Therefore, when touch enhancement is enabled—that is, when the user turns on the switch 903 in the game settings interface 901—the electronic device can increase the refresh rate to improve responsiveness during game application operation.

[0185] In other words, besides changes in the target frame rate of the game application triggering the game refresh rate decision module to determine the target refresh rate, touch events and the state of the touch enhancement switch can also trigger the game refresh rate decision module to make a target refresh rate decision. Therefore, when making a refresh rate decision, the game refresh rate decision module needs to consider not only the target frame rate of the game application but also the touch state.

[0186] For example, when a touch event is active or touch enhancement is enabled, the refresh rate can be increased to 120Hz to improve responsiveness. Therefore, when making a refresh rate decision, if a touch event is active or touch enhancement is enabled, the game refresh rate decision module will set the target refresh rate to 120Hz. If no touch event is active and touch enhancement is disabled, the game refresh rate decision module can determine the target refresh rate based on the target frame rate of the game application. That is, target refresh rate = target frame rate, or target refresh rate = maximum target frame rate.

[0187] In some embodiments, besides considering target applications like games, features such as split-screen and floating windows may allow other non-target applications to run in the foreground. When the focus window is a non-target application's window, it means that the non-target application is the main application used by the user (i.e., the focus application), such as... Figure 10 As shown, the game application runs as a floating window on top of the desktop application. In this case, the desktop application is the main application used by the user. Therefore, because non-target applications have different refresh rate requirements based on different smoothness needs, the target refresh rate cannot be determined solely by considering the target frame rate of the game application.

[0188] For example, when a desktop application is running, scrolling on the desktop requires high responsiveness and smooth visuals, so a high refresh rate is needed, such as 120Hz. However, when scrolling stops and the screen is statically viewed, high responsiveness and smooth visuals are not required, so the refresh rate requirement is reduced accordingly. Therefore, to save power, the refresh rate can be reduced, for example, from 120Hz to 10Hz, or even to 1Hz.

[0189] Therefore, when making refresh rate decisions, in addition to considering the frame rate requirements of the game application, the electronic device also needs to consider the refresh rate requirements of non-target applications running in the foreground. Furthermore, in this embodiment, after the game refresh rate decision module obtains a target refresh rate based on the target frame rate of the game application, it needs to further input the decided target refresh rate to the 2D / 3D refresh rate decision module. The 2D / 3D refresh rate decision module then determines the final target refresh rate based on the actual refresh rate of the game application and non-target applications running in the foreground.

[0190] Specifically, if no other non-target applications are running in the foreground, and only the game application is running, then the target refresh rate ultimately output by the 2D / 3D refresh rate decision module is the target refresh rate decided by the game refresh rate decision module.

[0191] However, when both the target application and non-target applications are running in the foreground, and if the window corresponding to the non-target application is the focused window, then the 2D / 3D refresh rate decision module needs to decide on the final target refresh rate based on the target refresh rate determined by the game refresh rate decision module and the refresh rate requirements of the non-target application.

[0192] For example, if the non-target application is a desktop application, Figure 11 A flowchart illustrating a refresh rate decision process is shown. The following embodiments of this application are combined with... Figure 11 The process of refresh rate decision-making is explained in detail.

[0193] As mentioned above Figure 2 and Figure 3 The relevant descriptions indicate that current refresh rate decisions, besides considering the frame rate requirements of target applications like games, also take into account scenarios with higher priority, such as low battery, virtual screen, and animation effects. Therefore, before the gaming scenario, there are other higher priority decision scenarios, such as low battery, virtual screen, animation effects, etc. Figure 11 As shown.

[0194] In other words, when making refresh rate decisions, if other scenarios with higher priority, such as low battery, virtual screen, animations, or others, also exist besides gaming, the game refresh rate decision module will not make the refresh rate decision. The game refresh rate decision module will only make the refresh rate decision when only the gaming scenario exists.

[0195] like Figure 11 The decision logic shown in the diagram first determines whether a touch event exists when the game refresh rate decision module makes a refresh rate decision. If a touch event exists, the game target refresh rate is determined to be 120Hz.

[0196] If no touch events occur, the system will further determine whether touch enhancement is enabled. If touch enhancement is enabled, the target game refresh rate is set to 120Hz. If touch enhancement is disabled, the target game refresh rate is further determined based on the game application's target frame rate. In other words, the target game refresh rate equals the maximum target frame rate.

[0197] Then, because it is necessary to consider the case where a non-target application is running in the foreground and the window is the focus window at the same time, after the game refresh rate decision module determines the game target refresh rate, it further inputs the game target refresh rate to the 2D / 3D refresh rate decision module, and then the 2D / 3D refresh rate decision module makes the refresh rate decision.

[0198] like Figure 11 As shown, the input data of the 2D / 3D refresh rate decision module includes at least one application refresh rate corresponding to the 2D desktop application. That is, the application refresh rate corresponding to the desktop application includes a first application refresh rate (maxfps) and a second application refresh rate (minfps). Simultaneously, the input data of the 2D / 3D refresh rate decision module also includes the game target refresh rate, which is the target refresh rate decided by the game scene refresh rate decision module (i.e., the first target refresh rate in this embodiment).

[0199] Then, if both the first application refresh rate (maxfps) and the second application refresh rate (minfps) are less than the game's target refresh rate, in order to ensure the performance of the game application, the second target refresh rate output by the 2D / 3D refresh rate decision module to SF is minfps = maxfps = game target refresh rate, and the display screen can directly refresh the screen according to the game target refresh rate.

[0200] However, if both the first application refresh rate (maxfps) and the second application refresh rate (minfps) are greater than the game's target refresh rate, it means that refreshing the screen according to the refresh rate of the non-target application can guarantee the performance of the game application. In this case, the second target refresh rate output by the 2D / 3D refresh rate decision module to SF includes the first application refresh rate (maxfps) and the second application refresh rate (minfps), thus simultaneously satisfying the refresh rate requirements of both the game application and the non-target application.

[0201] It should be noted that the target refresh rate output to SF in this application embodiment can be understood as the software refresh rate, therefore Figure 11 The second target refresh rate output to SF can include multiple values. SF then selects the appropriate refresh rate to synthesize the image based on the actual application scenario. In other words, when the user is swiping in the desktop application, SF will synthesize the image using the highest refresh rate among the second target refresh rates, such as the first application refresh rate (maxfps). When the desktop application is static, SF will synthesize the image using the lowest refresh rate among the second target refresh rates, such as the second application refresh rate (minfps).

[0202] However, in real-world scenarios, there is only one hardware refresh rate—the refresh rate at which the display refreshes its image. Therefore, although multiple refresh rates are possible as a second target refresh rate, the display can only use one of them. The refresh rate used by the display also depends on the actual application scenario. Specifically, the display can refresh at either the first application refresh rate (maxfps) or the second application refresh rate (minfps), depending on the application. For instance, when a user is swiping in a desktop application, the display refreshes at the first application refresh rate (maxfps). Once the user stops swiping and the application enters a static state, the display refreshes at the second application refresh rate (minfps).

[0203] If the first application's refresh rate (maxfps) is greater than the game's target refresh rate, but the second application's refresh rate (minfps) is less than the game's target refresh rate, then, to simultaneously meet the needs of both the desktop and game applications, the second target frame rate will include both the first application's maxfps and the game's target refresh rate. Therefore, when the user performs a swipe operation in the desktop application, the display refreshes the image according to the first application's maxfps. However, once the desktop application is static, the display needs to refresh the image according to the game's target refresh rate.

[0204] S9, the scheduling service performs capacity / resource scheduling based on the target frame rate.

[0205] After obtaining the target frame rate of the game application, the game target frame rate decision module not only sends the target frame rate to the game refresh rate decision module for refresh rate determination, but also needs to send it to the scheduling service. The scheduling service then performs processor capacity / resource scheduling based on the game application's target frame rate to ensure the game application's performance requirements. In other words, the target frame rate also needs to be used as input to the game scheduling scheme to ensure game performance.

[0206] In one specific embodiment, the game scheduling scheme is a frame scheduling scheme based on a frame interval feedback mechanism. That is, the frame interval of the past X frames (i.e., the historical frame interval) is used to determine whether the processor capacity / resource supply meets expectations, thereby deciding whether to increase or decrease the processor capacity / resources in the future. Therefore, whether the target frame rate is accurate also determines whether the processor capacity / resources can be supplied accurately.

[0207] Specifically, the scheduling service first calculates the expected frame interval based on the target frame rate of the game application. The calculation expression is: Expected frame interval = 1 / (Target frame rate ± tolerance). Here, the tolerance is the preset allowable error frame rate.

[0208] Then, if the expected frame interval matches the frame interval of the past X frames, it means that the processor capacity / resource supply is as expected, and no scheduling is needed. However, if the expected frame interval does not match the frame interval of the past X frames, it means that the processor capacity / resource supply is not as expected, and the processor capacity / resources need to be increased or decreased for the game application based on the difference.

[0209] It should be noted that the specific principles and implementation processes for adjusting processor capabilities / resources by the scheduling service can refer to any existing scheduling method, and the embodiments of this application do not limit this in any way. For example, the target application's rendering usually requires the support of processors such as CPU and GPU. Therefore, scheduling processor capabilities / resources can mean scheduling the capabilities / resources of the CPU and GPU to ensure the resource supply during the target application's rendering.

[0210] For example, taking a mobile phone as an example, Figure 12 This diagram illustrates an interface for refresh rate decision-making. The following section combines... Figure 12 The refresh rate decision method provided in the embodiments of this application will be described.

[0211] refer to Figure 12 As shown in (1), at the first moment, the mobile phone responds to the user's startup operation and starts running game application A. At this time, only one game application A is running in the foreground of the mobile phone, so the refresh rate of the display screen (i.e., the first target refresh rate) is determined based on the target frame rate A of this game application A. That is, if there is no touch event or touch enhancement is turned off, then the refresh rate = target frame rate A, as shown in (1). Figure 12 As shown in (1). If a touch event exists or touch is enabled, the refresh rate is equal to the refresh rate corresponding to the touch event or touch is disabled, such as 120Hz. The determination of the target frame rate A can be found in step S7 above, and will not be repeated here.

[0212] refer to Figure 12 As shown in (2), at the second moment, the phone responds again to the user's startup operation and starts running game application B through split-screen mode. At this time, game application A and game application B are running simultaneously in the foreground of the phone, which is a high-concurrency scenario. Therefore, the refresh rate of the display screen (i.e., the first target refresh rate) needs to be determined based on the target frame rate A of game application A and the target frame rate B of game application B.

[0213] For example, suppose the target frame rate A is less than the target frame rate B. That is, if there are no touch events or touch is disabled, then the refresh rate = the target frame rate B. Figure 12 As shown in (2). If a touch event exists or touch is enabled, the refresh rate is equal to the refresh rate corresponding to the touch event or touch is disabled, such as 120Hz. The determination of the target frame rate B can be referred to the description in step S7 above, and will not be repeated here.

[0214] refer to Figure 12 As shown in (3), at the third moment, the phone responds to the user's close operation and floating window launch operation, triggering the phone to end the running of game application B in the foreground and run game application A as a floating window on the desktop application in the foreground. At this time, the phone simultaneously runs game application A and desktop application in the foreground, and the desktop application is the focused window. Therefore, the refresh rate of the display screen (i.e., the second target refresh rate) needs to be determined based on the application refresh rate corresponding to the desktop application and the target frame rate A based on game application A.

[0215] That is, firstly, the required refresh rate for game application A is determined based on the target frame rate A of game application A (i.e., the game's target refresh rate / the first target refresh rate). Then, the second target refresh rate is determined based on the application refresh rate of the desktop application and the first target refresh rate. In this scenario, the determined second target refresh rate can be understood as the final determined refresh rate.

[0216] For example, suppose that at least one application refresh rate for the desktop application includes 120Hz and 1Hz, and suppose that the target frame rate A = 60fps. Therefore, the first target refresh rate can be determined to be 60Hz. Then, depending on whether the user performs a swipe operation, the display refresh rate can be either 120Hz or the refresh rate can be the first target refresh rate of 60Hz.

[0217] Another embodiment of this application provides an electronic device, including: one or more processors and a memory. The memory is coupled to the processor; the memory stores one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device implements the refresh rate decision method described in any of the above embodiments.

[0218] Another embodiment of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor in an electronic device, causes the electronic device to implement the refresh rate decision method described in any of the above embodiments.

[0219] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps described in the above method embodiments.

[0220] This application also provides a chip system, such as... Figure 13 As shown, the chip system 130 includes at least one processor 1301 and at least one interface circuit 1302. The processor 1301 and the interface circuit 1302 are interconnected via lines. For example, the interface circuit 1302 can be used to receive signals from other devices (e.g., a computer's memory). As another example, the interface circuit 1302 can be used to send signals to other devices (e.g., the processor 1301).

[0221] For example, interface circuit 1302 can read instructions stored in memory and send those instructions to processor 1301. When the instructions are executed by processor 1301, the computer can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0222] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0223] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0224] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0225] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0226] If the function of the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0227] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A refresh rate decision method, characterized in that, Applied to an electronic device, the electronic device including the target application; the method includes: Run at least one of the target applications in the foreground; For each target application, the target frame rate is determined based on the frame rate strategy corresponding to the target application. Based on the target frame rate corresponding to the target application, schedule processor resources for the target application respectively; A first target refresh rate is determined based on the target frame rate of all target applications, and the display screen of the electronic device refreshes the screen according to the first target refresh rate.

2. The method according to claim 1, characterized in that, The electronic device further includes a non-target application, which corresponds to at least one application refresh rate, and different application refresh rates correspond to different application scenarios of the non-target application; the method further includes: If at least one non-target application is running in the foreground and the focused window is the window of the non-target application, a second target refresh rate is determined based on the first target refresh rate and the refresh rate of the at least one application, and the display screen of the electronic device refreshes the screen according to the second target refresh rate. Wherein, the second target refresh rate includes at least one of the first target refresh rate and the at least one application refresh rate; if there is an application refresh rate greater than the first target refresh rate among the at least one application refresh rates, the second target refresh rate includes the application refresh rate greater than the first target refresh rate; if there is an application refresh rate less than the first target refresh rate among the at least one application refresh rate, the second target refresh rate does not include the application refresh rate less than the first target refresh rate; if all at least one application refresh rate are less than the first target refresh rate, the second target refresh rate includes only the first target refresh rate; When the second target refresh rate includes only the first target refresh rate, the screen is refreshed according to the first target refresh rate; when the second target refresh rate does not include only the first target refresh rate, a refresh rate is selected from the second target refresh rates based on the application scenario of the non-target application for screen refresh.

3. The method according to claim 2, characterized in that, The non-target applications include desktop applications, and the application refresh rate includes a first application refresh rate and a second application refresh rate, wherein the first application refresh rate is greater than the second application refresh rate. The step of determining a second target refresh rate based on the first target refresh rate and the refresh rate of at least one application, and refreshing the screen of the electronic device according to the second target refresh rate, includes: When the second application refresh rate is greater than the first target refresh rate, it is determined that the second target refresh rate includes both the first application refresh rate and the second application refresh rate. The display screen of the electronic device refreshes the screen according to the first application refresh rate or the second application refresh rate based on the application scenario of the non-target application. When the refresh rate of the second application is less than the first target refresh rate, the second target refresh rate is determined to include both the refresh rate of the first application and the first target refresh rate. The display screen of the electronic device refreshes the screen according to the refresh rate of the first application or the first target refresh rate based on the application scenario of the non-target application. The application scenario corresponding to the first target refresh rate is the application scenario corresponding to the second application refresh rate. When the first target refresh rate is greater than the first application refresh rate, the second target refresh rate is the first target refresh rate, and the display screen of the electronic device refreshes the image according to the first target refresh rate.

4. The method according to any one of claims 1-3, characterized in that, The frame rate strategy includes preset limiting strategies and overlay strategies; the limiting strategy has a higher priority than the overlay strategy; determining the target frame rate based on the frame rate strategy corresponding to the target application includes: The target policy is obtained from the frame rate policy corresponding to the target application according to the policy pointer; the target policy includes the frame rate policy pointed to by the policy pointer and the frame rate policy with a higher policy priority than the frame rate policy pointed to by the policy pointer. For the restriction policy in the target policy, the minimum frame rate is obtained from the frame rates corresponding to the restriction policy as the first candidate frame rate; For the coverage strategy in the target strategy, the frame rate corresponding to the coverage strategy with the highest priority is used as the second candidate frame rate; wherein, when the coverage strategy does not exist in the target strategy, the second candidate frame rate is empty. When the first candidate frame rate is less than the second candidate frame rate and the first candidate frame rate is less than the previous target frame rate, the first candidate frame rate is taken as the target frame rate. When the first candidate frame rate is greater than or equal to the second candidate frame rate, and the second candidate frame rate is not equal to the previous target frame rate, the second candidate frame rate is taken as the target frame rate.

5. The method according to any one of claims 1-4, characterized in that, The determination of the first target refresh rate based on the target frame rate of all target applications includes: If there is no touch event and touch enhancement is off, the maximum frame rate among the target frame rates corresponding to all target applications is taken as the first target refresh rate; If a touch event exists or touch enhancement is enabled, the refresh rate corresponding to the touch event or touch enhancement is used as the first target refresh rate.

6. The method according to any one of claims 1-5, characterized in that, The determination of the first target refresh rate based on the target frame rate of all target applications includes: In all refresh rate decision scenarios, if the target application has the highest decision priority, then the first target refresh rate is determined based on the target frame rate of all target applications.

7. The method according to any one of claims 1-6, characterized in that, The step of scheduling processor resources for the target application according to the target frame rate corresponding to the target application includes: The expected frame interval of the target application is determined based on the target frame rate and the preset error frame rate; When the expected frame interval does not match the historical frame interval of the target application, processor resources are scheduled for the target application.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Based on the system restriction information, the application scenario of the target application, the frame rate scheme requirements, and any one or more of the frame rate performance of the target application, a frame rate strategy for the target application is generated accordingly. The strategy types of the frame rate strategy include restriction strategy and coverage strategy. The system limitation information includes one or more of the following: temperature-controlled frame rate limiting, non-target scene limitations, the maximum frame rate allowed by the target application, and the preset default frame rate of the target application; the scene information includes one or more of the following: the application scene of the target application, split-screen status, and instantaneous power consumption; the frame rate scheme includes one or more of the following: hardware frame interpolation, software frame interpolation, and frame rate easing; the frame rate performance includes one or more of the following: the set frame rate of the target application, the real-time frame rate tier, and the self-limiting frame rate of the target application; the real-time frame rate tier is determined based on the rendering rate of the target application, and the self-limiting frame rate is determined based on the real-time frame rate tier.

9. The method according to claim 8, characterized in that, The method further includes: Obtain at least two consecutively rendered image frames from the target application, wherein the number of image frames is equal to a preset number; When the frame rate corresponding to the target frame interval is less than the real-time frame rate level, it is determined that the target application has an application self-limiting frame; wherein, the target frame interval is determined based on the frame interval of the image frame; When the target application has an application self-limiting frame, i image frame sets are continuously acquired. The number of image frames included in each image frame set is equal to the quotient of the preset number divided by i; i > 1, and i is a positive integer. The self-limited frame rate of the target application is determined based on the i frame intervals corresponding to the i image frame sets and the target frame interval.

10. The method according to claim 8 or 9, characterized in that, The frame rate strategy further includes a high refresh rate triggering strategy, which is used to increase the target frame rate of the target application; the method further includes: When a sudden increase in the frame rate of the target application is determined based on the real-time frame rate level of the target application, the high refresh rate triggering strategy is added to the target application. After the added time reaches the preset time or the frame rate of the target application drops, the added high refresh rate triggering strategy is deleted; wherein, the strategy priority of the high refresh rate triggering strategy is lower than the strategy priority of setting the frame rate.

11. The method according to any one of claims 1-10, characterized in that, The frame rate policy corresponding to the target application is dynamically changed based on the operating state of the electronic device; determining the target frame rate based on the frame rate policy corresponding to the target application includes: When the frame rate policy corresponding to the target application changes, the target frame rate is determined based on the frame rate policy corresponding to the target application; the change includes adding, deleting, and updating the frame rate corresponding to the frame rate policy. Specifically, when adding or updating, the policy pointer moves to the newly added frame rate policy or the updated frame rate policy; when deleting, the policy pointer moves to the preset deletion policy, which is added when the frame rate policy is deleted for the target application for the first time.

12. The method according to any one of claims 1-11, characterized in that, The target application includes a frame rate setting function, which is used to set the frame rate of the target application, including game applications.

13. An electronic device, characterized in that, include: One or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device causes the electronic device to perform the refresh rate decision method as described in any one of claims 1-12.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor of the electronic device, the electronic device performs the refresh rate decision method as described in any one of claims 1-12.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor in an electronic device, the electronic device performs the refresh rate decision method as described in any one of claims 1-12.

Images