Method for requesting vSync signal and electronic equipment

Abstract

The invention provides a vSync signal requesting method and electronic equipment, relates to the technical field of image display, and can reduce the possibility of lagging and unsmoothness when multiple frames of continuous images which change dynamically need to be displayed. At a first moment, a first application in the electronic equipment calls a setVsyncRate interface of a window system SF in the electronic equipment, a first request is sent to the SF, and the first request is used for requesting a vSync signal. In response to the first request, the SF periodically distributes vSync signals to the first application. And at the second moment, the first application calls the setVsyncRate interface and sends a second request to the SF, the second request is used for requesting to cancel the vSync signal, and after the SF receives the second request, periodic distribution of the vSync signal to the first application is ended.

Description

Method and electronic device for requesting vSync signal

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on September 14, 2022, with application number 202211116851.3 and invention name “A method and electronic device for requesting vSync signal”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of image display technology, and in particular to a method and electronic device for requesting a vSync signal. Background Art

[0003] When the display screen of electronic devices such as mobile phones and tablets is on, the application can request a vertical synchronization (vSync) signal when it needs to display a new frame of image, and the display screen of the electronic device can distribute the vSync signal to the application that requested the vSync signal after one refresh, that is, to the application with rendering requirements. The vSync signal can trigger the application to complete the rendering of a new frame of image, and then synthesize it and finally send it for display. In this way, after the display screen is refreshed once, the application with rendering requirements is triggered to start rendering a new frame of image, which is then synthesized and sent for display. This ensures that the number of frames per second (Frame Per Second, FPS) of the picture will not exceed the refresh rate of the display screen. For example, if the refresh rate is 60 Hz (HZ), it can be guaranteed that the FPS does not exceed 60 frames per second.

[0004] However, in the process of implementing the embodiments of the present application, the inventors discovered that in the prior art, when the load of the electronic device is high, such as when the central processing unit (CPU) occupancy exceeds 97%, the application's request for the vSync signal will have a very long delay. If the application's request for the vSync signal is not received in a timely manner, the vSync signal will naturally not be distributed to the application, and the application will not be triggered to complete the rendering of the new frame of the image in time, resulting in the display screen being unable to obtain the new frame of the image and ultimately only being able to display the old image. In particular, when it is necessary to display multiple frames of dynamically changing continuous images, if the above problem occurs, the dynamic change process will be jerky and not smooth.

[0005] Summary of the Invention

[0006] In view of this, the present application provides a method and electronic device for requesting a vSync signal, which can reduce the possibility of freezes and unsmoothness when it is necessary to display dynamically changing continuous multi-frame images.

[0007] In a first aspect, embodiments of the present application provide a method for requesting a vSync signal, for use in an electronic device with a display function, such as a mobile phone or tablet, wherein a first application is installed in the electronic device. At a first moment, the first application in the electronic device invokes the setVsyncRate interface of the window system (SF) in the electronic device and sends a first request to the SF, wherein the first request is for requesting a vSync signal. In response to the first request, the SF periodically distributes a vSync signal to the first application.

[0008] It should be understood that SF periodically distributes vSync signals to the first application, and the first application can periodically receive vSync signals. The vSync signal can trigger the rendering of the image. The first application periodically receives the vSync signal and can periodically render the image. In this way, the first application only requests the vSync signal once, and can complete the rendering of multiple frames of images without requesting multiple vSync signals for multiple frames of images. This can reduce cross-process calls between the application process and the SF process, and reduce dependence on the Binder thread. In this way, in scenarios where dynamically changing continuous multiple-frame images need to be displayed, the possibility of display freezes and unsmoothness can be reduced.

[0009] At a second moment, the first application calls the setVsyncRate API to send a second request to the SF, requesting to cancel the vSync signal. Upon receiving the second request, the SF stops periodically sending vSync signals to the first application. This allows the SF to be promptly triggered to stop periodically sending vSync signals to the first application when the signal is no longer needed, thus avoiding resource waste caused by long-term periodic vSync signaling.

[0010] In one possible design, the method further includes: the first application determining that multiple consecutive image frames need to be rendered, the first moment including a moment of requesting rendering of a first image, the first image being the first frame of the multiple image frames. Thus, when the first frame of the multiple image frames needs to be rendered, the setVsyncRate interface is called to request a vSync signal from the SF. Thus, upon determining that multiple consecutive image frames need to be rendered, the SF can promptly begin periodically distributing vSync signals, triggering the sequential rendering of the multiple image frames.

[0011] In one possible design, a first application records a first switch state, and a rendering module in a framework layer of the electronic device records a second switch state, where the initial values ​​of the first switch state and the second switch state are both off. After the first application determines that multiple consecutive image frames need to be rendered, the method further includes: the first application updating the first switch state to on, so that the first switch state indicates that multiple consecutive image frames need to be rendered.

[0012] In the above, at the first moment, the first application in the electronic device calls the setVsyncRate interface of the window system SF in the electronic device to send a first request to SF, including: at the first moment, the first application sends a first message to the rendering module, the first message being used to request a vSync signal. In response to the first message, and provided that the first switch state is on and the second switch state is off, the rendering module calls the setVsyncRate interface to send the first request to SF.

[0013] Among them, the first switch state is on and the second switch state is off, indicating that the first application has just changed from not needing to render multiple consecutive frames of images to needing to render multiple consecutive frames of images. Therefore, the rendering module needs to call the setVsyncRate interface to request the vSync signal and trigger SF to periodically distribute the vSync signal in time.

[0014] In one possible design, the first switch state is on and the second switch state is off. The above method also includes: the rendering module updates the second switch state to on, so that the second switch state in the rendering module can also synchronously indicate that the first application needs to render multiple consecutive frames of images.

[0015] In one possible design, the method further includes: at a third moment, the first application does not request a vSync signal from the SF. The third moment is the moment of requesting rendering of a second image, where the second image is any image in the multi-frame image except the first frame. In this way, when rendering the second frame and subsequent images in the multi-frame image, the first application does not repeatedly call the setVsyncRate interface to request a vSync signal from the SF. This allows the first application to request a vSync signal only once when rendering multiple consecutive frames, reducing cross-process calls.

[0016] Specifically, at the third moment, the first application sends a first message to the rendering module, and the first message is used to request a vSync signal. In response to the first message, and the first switch state is on and the second switch state is on, the rendering module does not request a vSync signal from the SF. The first switch state is on, indicating that the first application needs to render multiple frames of images in succession. However, the second switch state is also on, indicating that the first application has not just changed from not needing to render multiple frames of images in succession to needing to render multiple frames of images in succession. Therefore, the rendering module does not need to repeatedly call the setVsyncRate interface to request a vSync signal. Then, when the first switch state is on and the second switch state is on, there is no need to repeatedly call the requestNextVsync interface to request a vSync signal. This avoids repeatedly calling the requestNextVsync interface to request a vSync signal, ensuring that in scenarios where multiple frames of images need to be rendered in succession, the vSync signal is only requested once by calling the requestNextVsync interface.

[0017] In one possible design, the method further includes: the first application determines that rendering of the multiple consecutive frames has ended, and the second moment includes a moment of requesting rendering of a third image, where the third image is the first frame that the first application needs to render after rendering of the multiple frames has completed. In this manner, after rendering of the multiple frames is completed and a new frame needs to be rendered, the setVsyncRate interface is called to request the SF to cancel the vSync signal. This allows the SF to promptly stop periodically issuing vSync signals after rendering of the multiple frames is completed, thereby saving resources.

[0018] In one possible design, after the first application determines that it has finished rendering multiple consecutive frames of images, the method further includes: the first application updating the first switch state to off. At the second moment, the first application calls the setVsyncRate interface to send a second request to the SF, including: at the second moment, the first application sends a first message to the rendering module, the first message being used to request a vSync signal. In response to the first message, and with the first switch state being off and the second switch state being on, the rendering module calls the setVsyncRate interface to send a second request to the SF.

[0019] Among them, the first switch state is the off state, and the second switch state is the on state, indicating that the first application has just changed from needing to render multiple consecutive frames of images to not needing to render multiple consecutive frames of images. Therefore, the rendering module needs to first call the setVsyncRate interface to request to cancel the vSync signal to avoid SF still periodically distributing the vSync signal after the need to render multiple consecutive frames of images ends.

[0020] In one possible design, the first switch state is an off state, and the second switch state is an on state. The above method also includes: the rendering module updates the second switch state to an off state, so that the second switch state in the rendering module can also synchronously indicate that the first application does not need to render multiple consecutive frames of images.

[0021] In one possible design, after sending the second request to the SF, the method further includes: the first application calling the requestNextVsync interface of the SF to send a third request to the SF, the third request being for a vSync signal. In response to the third request, the SF distributes a vSync signal to the first application.

[0022] That is, using the method of this embodiment, after triggering the SF to end periodic vSync signal distribution, a vSync signal can be further requested from the SF, so that the SF can distribute the vSync signal to trigger the first frame of image after the first application renders multiple frames of image. Thus, after the rendering of multiple consecutive frames of image is completed, a vSync signal is requested once and a vSync signal is distributed once.

[0023] In one possible design, the SF periodically distributes a vSync signal to the first application, including periodically distributing the vSync signal to the rendering module. It should be understood that the first application requires the rendering module to perform rendering. Distributing the vSync signal to the rendering module by the SF can trigger the rendering module to complete image rendering for the first application. Therefore, distributing the vSync signal to the rendering module by the SF is equivalent to distributing the vSync signal to the first application.

[0024] In one possible design, the method further includes: when the first application needs to render a fourth image, sending a first message to the rendering module. The fourth image is any frame image that the first application needs to display, and the fourth image may include the first image or the second image. In response to the first message, the rendering module records a first flag and deletes the first flag after receiving a vSync signal from the service provider. Each time the rendering module receives a vSync signal from the service provider, it may determine whether the processing status is unprocessed. If the processing status is unprocessed, indicating that the first application has an image to render, the rendering module may be triggered to render the image and update the processing status to processed. If the processing status is not unprocessed, indicating that the first application does not have an image to render. In other words, the currently received vSync signal is redundant. It should be understood that when a vSync signal is requested from the service provider by calling the requestNextVsync interface, the service provider issues a vSync signal once per request and does not issue redundant vSync signals. Therefore, the redundant vSync signals are most likely periodically issued by the service provider after the service provider requests a vSync signal from the service provider by calling the setVsyncRate interface. If the first application requests the SF to cancel the vSync signal at a second time, the second time may be the time when the rendering module receives the vSync signal from the SF without the first flag. In this way, the rendering module can promptly trigger the SF to stop periodically distributing the vSync signal after discovering the redundant vSync signal.

[0025] In one possible design, the above method also includes: at the second moment, the rendering module notifies the first application to update the first switch state to the off state, and the rendering module updates the second switch state to the off state, so that both the first switch state and the second switch state indicate the end of rendering of multiple consecutive frames of images.

[0026] In one possible design, the method further includes: at a fourth moment, the first application sends a first message to the rendering module, the first message being used to request a vSync signal. In response to the first message, and with both the first switch state and the second switch state being off, the rendering module calls a requestNextVsync interface to send a fourth request to the SF, the fourth request being used to request a vSync signal.

[0027] If the first switch state is off, it indicates that the first application does not need to render multiple consecutive frames. Furthermore, the local switch state of the rendering module is off, indicating that rendering of multiple consecutive frames has not just finished. Therefore, the rendering module does not need to call the requestNextVsync interface to request the cancellation of the vSync signal. If both the first and second switch states are off, the requestNextVsync interface can be called to request the vSync signal.

[0028] In one possible design, the SF is located in the local layer of the electronic device, and the first application is located in the application layer of the electronic device. Before sending the first request to the SF, the method further includes: adding a first interface to the framework layer of the electronic device and adding a second interface to the Java native interface layer of the electronic device, where the first interface and the second interface are interfaces open to Java by the setVsyncRate interface. The first application calling the setVsyncRate interface includes: the first application sequentially calling the setVsyncRate interface through the first interface and the second interface.

[0029] That is, with this embodiment, a path is opened between the first application and the SF in the local layer through the first interface, the second interface and the setVsyncRate interface, so that the application can call the setVsyncRate interface to request a vSync signal from the SF.

[0030] In one possible design, the first request includes a period n, where n≥1 and n is an integer. In response to the first request, the SF periodically distributes a vSync signal to the first application, including: in response to the first request, the SF distributes a vSync signal to the first application once after receiving n vSync signals.

[0031] That is, using this embodiment, the first application can flexibly specify the period for the SF to distribute the vSync signal according to display requirements.

[0032] In a second aspect, an embodiment of the present application provides an electronic device, which includes a memory and a processor, and the memory and the processor are coupled; wherein computer program code is stored in the memory, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method as in the first aspect and any possible design method thereof.

[0033] In a third aspect, an embodiment of the present application provides a chip system, which is applied to an electronic device including a display screen and a memory; the chip system includes one or more interface circuits and one or more processors; the interface circuit and the processor are interconnected by lines; the interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor, the signal including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device executes the method described in the first aspect and any possible design method thereof.

[0034] In a fourth aspect, the present application provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the method described in the first aspect and any possible design thereof.

[0035] In a fifth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method described in the first aspect and any possible design thereof.

[0036] It can be understood that the beneficial effects that can be achieved by the electronic device described in the second aspect, the chip system described in the third aspect, the computer storage medium described in the fourth aspect, and the computer program product described in the fifth aspect provided above can refer to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] FIG1 is a schematic diagram of an interface of a desktop animation provided by an embodiment of the present application;

[0038] FIG2 is a schematic diagram of an image processing process provided in an embodiment of the present application;

[0039] FIG3 is a timing diagram of an image processing method provided in an embodiment of the present application;

[0040] FIG4 is a schematic diagram of an interface of another desktop animation provided in an embodiment of the present application;

[0041] FIG5 is a schematic diagram showing the principle of a method for requesting a vSync signal provided by an embodiment of the present application;

[0042] FIG6 is a hardware structure diagram of an electronic device provided in an embodiment of the present application;

[0043] FIG7 is a software architecture diagram of an electronic device provided in an embodiment of the present application;

[0044] FIG8 is a timing diagram of a method for requesting a vSync signal provided by an embodiment of the present application;

[0045] FIG9 is a schematic diagram of a state transition of a request state provided in an embodiment of the present application;

[0046] FIG10 is a timing diagram of another method for requesting a vSync signal provided by an embodiment of the present application;

[0047] FIG11 is a timing diagram of another method for requesting a vSync signal provided by an embodiment of the present application;

[0048] FIG12 is a timing diagram of another method for requesting a vSync signal provided by an embodiment of the present application;

[0049] FIG13 is a schematic structural diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application are described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing specific embodiments, and are not intended to be used as limitations on the present application. As used in the specification and claims of the present application, the singular expressions "a", "said", "above", "the" and "this" are intended to also include expressions such as "one or more", unless there is a clear contrary indication in the context. It should also be understood that in the following embodiments of the present application, "at least one", "one or more" refer to one or more (including two). The term "and / or" is used to describe the association relationship of associated objects, indicating that three relationships can exist; for example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0051] References to "one embodiment" or "some embodiments" etc. described in this specification mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in another way. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in another way. The term "connected" includes direct and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated.

[0052] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0053] The present invention provides a method for requesting a vSync signal, which can be used in scenarios where a dynamically changing continuous multi-frame image needs to be displayed. Specifically, the scenario where a dynamically changing continuous multi-frame image needs to be displayed refers to a scenario where an application needs to continue displaying animations such as sliding and zooming after a user touch operation ends.

[0054] For example, referring to FIG1 , after the mobile phone detects a user clicking on the video application icon 102 on the desktop 101 (i.e., after the click operation is completed), it will sequentially display the dynamically changing animation effects shown in desktop 103, desktop 104, desktop 105, desktop 106, and desktop 107 to transition, and finally display the application interface of the video application (not shown in FIG1 ). The scene shown in FIG1 above is a scene that requires displaying dynamically changing continuous multiple frames of images.

[0055] Typically, displaying a single image frame involves three steps: rendering, compositing, and sending to the display. The application that generates the image to be displayed performs the rendering step, rendering the content of each layer of the image to be displayed. The application then sends the rendered layer data to the window system (SurfaceFlinger, SF). SF performs the compositing step based on the layer data, completing the layer composition and producing the image to be processed. Finally, SF performs the sending step, sending the image to the display screen for display.

[0056] Meanwhile, referring to Figure 2, numbers 1-4 represent frames 1-4. The solid, unfilled rectangles represent the rendering process, the dashed, unfilled rectangles represent the compositing process, and the solid, filled rectangles represent the display process. Clearly, except for frame 1, the rendering of all other images is triggered by the vSync signal. Specifically, the display refreshes according to its refresh rate. For example, if the display refresh rate is 60 Hz, meaning it refreshes 60 times per second, the display refreshes at intervals of 1 / 60s (≈ 16.67ms). Of course, the display refresh rate can also be 90 Hz, 120 Hz, or similar. After a refresh, the display generates a vSync signal, which is distributed to the application via the SF, triggering the application to begin rendering. After the application completes rendering, the SF performs compositing and finally sends it to the display. In this way, rendering and compositing of a new frame are triggered only after each display refresh. This ensures that the FPS does not exceed the display refresh rate.

[0057] During the use of electronic devices, different applications have different requirements for rendering. Normally, whether an application has a rendering requirement needs to be determined by the application based on its own display logic. Taking Figure 1 as an example, only the Launcher knows that after detecting the user's click operation on the application icon on the desktop, it needs to display the animation corresponding to desktop 103-desktop 107. Accordingly, it is necessary to continuously render multiple frames of images included in the animation. For example, desktop 103-desktop 107 correspond to the 1st frame to the 5th frame animation, and 5 animation frames need to be rendered continuously. Therefore, after the application generates a rendering requirement, it is necessary to request a vSync signal from the SF to instruct the SF to further distribute it after receiving the vSync signal from the display screen, so as to trigger the application with rendering requirements (such as the Launcher) to start rendering and meet the rendering requirements.

[0058] In some embodiments, referring to FIG3 , the specific implementation from the application generating a rendering request to the final display of a frame of image includes:

[0059] S301 , when application 1 needs to render image 1 , it calls the requestNextVsync interface of SF to request a vSync signal from SF.

[0060] Application 1 (also referred to as the first application) can be any application in an electronic device, and Image 1 is any frame of image that Application 1 needs to display. SF can be used to distribute vSync signals to applications (such as Application 1) that require rendering, thereby triggering the application (such as Application 1) to start rendering. The requestNextVsync interface in SF is used by an application (such as Application 1) to request a vSync signal. That is, the application (such as Application 1) requests SF to distribute the vSync signal to the application (such as Application 1) to trigger the application (such as Application 1) to start rendering.

[0061] Taking Application 1 as an example, which is Launcher, when the Launcher determines that it needs to render the first frame of animation corresponding to the desktop 103 shown in Figure 1, it can call SF's requestNextVsync interface to request the vSync signal, that is, request SF to distribute the vSync signal to the Launcher to trigger the Launcher to start rendering the first frame of animation.

[0062] In this embodiment, application 1 requests a vSync signal by calling the requestNextVsync interface. This has the following characteristics: after application 1 requests a vSync signal once, the SF only distributes the vSync signal to application 1 once, thereby triggering application 1 to complete rendering of image 1. Subsequently, if application 1 needs to continue rendering, such as rendering image 2, image 3, and so on, it needs to call the requestNextVsync interface again to request a vSync signal.

[0063] For example, the SF records the request status of Application 1, which includes two types: unrequested and requested. The initial value of the request status is unrequested. After receiving a request for a vSync signal from Application 1, the SF updates the request status to requested, as shown in S302 below, indicating that Application 1 has a rendering request. After the SF distributes a vSync signal to Application 1, the request status is updated to unrequested, as shown in S305 below, indicating that Application 1 does not have a rendering request.

[0064] S302: The SF update request status is "requested".

[0065] S303: After a refresh is completed, the display screen sends a vSync signal to the SF.

[0066] After each refresh, the display sends a vSync signal to SF to indicate the start of the display process of the next frame of image, such as rendering, synthesis and display.

[0067] It should be understood that the display screen will refresh the display according to its refresh rate. For example, if the refresh rate of the display screen is 60 Hz (60 times per second), the display screen will refresh the display at an interval of 1 / 60s≈16.67ms.

[0068] S304 : When the request status is requested, SF distributes a vSync signal to application 1 .

[0069] After receiving the vSync signal, the SF can query the request status of Application 1. If the request status is "Requested", it means that Application 1 has a rendering requirement. In this case, the SF distributes the vSync signal to Application 1 to trigger Application 1 to start rendering.

[0070] It should be understood that if multiple applications request vSync signals, it means that multiple applications have rendering requirements, and SF needs to distribute vSync signals to multiple applications.

[0071] S305: The SF update request status is not requested.

[0072] S306 : Application 1 renders Image 1 in response to the vSync signal.

[0073] Application 1 starts rendering each time it receives a vSync signal, so that the application's frame rate is consistent with the display rate of the display.

[0074] S307. Application 1 sends rendered layer data to SF.

[0075] S308 , SF completes the synthesis process of image 1 .

[0076] SF can also be used for compositing, which mainly refers to compositing one or more layers.

[0077] S309. SF sends the synthesized image 1 to the display screen.

[0078] S310 , the display screen displays image 1.

[0079] With this embodiment, application 1 can request a vSync signal by calling the requestNextVsync interface of SF when it needs to render any frame of image. Subsequently, SF will distribute a vSync signal to application 1, thereby triggering application 1 to complete the rendering of one frame of image. Accordingly, in a scenario where it is necessary to display multiple frames of dynamic images, application 1 needs to render multiple frames of images continuously. Accordingly, application 1 needs to call the requestNextVsync interface of SF multiple times in succession to request a vSync signal. Taking Figure 1 as an example, application 1 is Launcher. When Launcher needs to render the first frame of animation corresponding to desktop 103, it needs to call the requestNextVsync interface to request a vSync signal for the first time; when Launcher needs to render the second frame of animation corresponding to desktop 104, it needs to call the requestNextVsync interface to request a vSync signal for the second time... When Launcher needs to render the fifth frame of animation corresponding to desktop 107, it needs to call the requestNextVsync interface to request a vSync signal for the fifth time.

[0080] However, Application 1's call to the requestNextVsync interface in the SF is a cross-process call between different processes, requiring the Binder thread in the SF to implement the call. The Binder thread has a low priority. When the electronic device is heavily loaded, such as when the CPU usage reaches 97% or above, the electronic device typically cannot prioritize CPU resources for the Binder thread to process the requestNextVsync interface call. The Binder thread is forced to wait for CPU resources. This causes the Binder thread to remain in a waiting (Runnable) state for a long time, preventing it from processing the requestNextVsync interface call in a timely manner. Consequently, the SF will not receive Application 1's request for the vSync signal in a timely manner. Subsequently, when the SF receives the vSync signal, it will not be distributed to Application 1, preventing Application 1 from rendering the image. Ultimately, the display will only display the previous image, not the next frame. This is particularly true in scenarios where dynamic, continuous multi-frame image display is required. Application 1 needs to render multiple frames, requiring frequent use of the Binder thread to process the requestNextVsync interface call, making the aforementioned issue more likely.

[0081] Moreover, in scenarios where multiple frames of dynamic images need to be displayed, if a new frame cannot be displayed in time, the dynamic change process will eventually cause the display to freeze and become unsmooth. As shown in FIG4 , when the load of the mobile phone is normal, the image can be displayed according to the process shown in FIG3 , and the display screen can display the first frame of the dynamic effect (such as desktop 401) and the second frame of the dynamic effect (such as desktop 402a) in sequence. After that, the load of the mobile phone increases, and it is impossible to display the image according to the process shown in FIG3 . The display screen can only display the second frame of the dynamic effect, such as desktop 402b and desktop 402c. After that, when the load of the mobile phone decreases, the mobile phone can continue to display the image according to the process shown in FIG3 , but at this time it is necessary to render the fifth frame of the dynamic effect. The Launcher will render the fifth frame of the dynamic effect, and will eventually display the fifth frame of the dynamic effect corresponding to desktop 403. Obviously, the display screen displays the second frame of the dynamic effect for three consecutive frames, which causes freezes, and directly transitions from the second frame of the dynamic effect to the fifth frame of the dynamic effect, and the dynamic effect transition is not smooth.

[0082] To address the above issues, embodiments of the present application provide a method for requesting a vSync signal. This method can be applied to scenarios similar to Figure 1 where a dynamically changing, continuous multi-frame image needs to be displayed. In these scenarios, the corresponding application needs to render multiple consecutive frames. Referring to Figure 5 , after Application 1 determines that it needs to render multiple consecutive frames, it can call the SF's setVsyncRate interface to request a vSync signal from the SF (e.g., at time t1 in Figure 5 ). Upon receiving Application 1's request for a vSync signal via the setVsyncRate interface, the SF periodically distributes the vSync signal to Application 1. This periodically triggers Application 1 to render images. In this way, Application 1 can render multiple consecutive frames. Subsequently, after Application 1 determines that it has finished rendering multiple consecutive frames, it can call the SF's setVsyncRate interface to request the SF to cancel the vSync signal (e.g., at time t2 in Figure 5 ). Upon receiving Application 1's cancellation of the vSync signal request via the setVsyncRate interface, the SF stops periodically distributing the vSync signal to Application 1. For the sake of convenience, time t1 can be called the first time, time t2 can be called the second time, the request to call the setVsyncRate interface to request the vSync signal can be called the first request, and the request to call the setVsyncRate interface to cancel the vSync signal can be called the second request.

[0083] In summary, using the embodiment of the present application, application 1 only needs to request a vSync signal from SF once, and then it can receive the vSync signal periodically distributed by SF, thereby periodically triggering application 1 to start rendering. Especially in scenarios where it is necessary to display dynamically changing continuous multi-frame images, SF periodically distributes vSync signals, thereby periodically triggering application 1 to complete the rendering of the continuous multi-frame images. There is no need for application 1 to continuously request multiple vSync signals, which greatly reduces the number of cross-process calls and reduces dependence on Binder threads. In this way, the possibility of display freezes and unsmoothness during dynamic changes can be reduced. In addition, application 1 can request to cancel the vSync signal, so that SF stops periodically distributing vSync signals to application 1, avoiding waste of resources caused by long-term periodic distribution.

[0084] Still taking the scenario of displaying desktop animation shown in Figure 1 as an example, after the Launcher detects the user's click operation on the application icon 102 of the video application in the desktop 101, the Launcher can determine that it needs to render the multi-frame animation shown in the desktop 103-desktop 107, that is, it needs to render continuous multi-frame images. In this case, the Launcher can call the setVsyncRate interface of SF to request the vSync signal from SF, triggering SF to periodically distribute the vSync signal to the Launcher. The periodic vSync signal can trigger the Launcher to render the multi-frame animation shown in the desktop 103-desktop 107 in sequence. After completing the rendering of the multi-frame animation, the Launcher can determine to end the rendering of the continuous multi-frame images. In this case, the Launcher can call the setVsyncRate interface of SF to request the SF to cancel the vSync signal, triggering SF to end the periodic distribution of the vSync signal to the Launcher, thereby reducing resource waste.

[0085] For example, the electronic device in the embodiments of the present application can be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook computer, as well as a cellular phone, personal digital assistant (PDA), augmented reality (AR) or virtual reality (VR) device, etc., which supports display functions. The embodiments of the present application do not impose any special restrictions on the specific form of the electronic device. Hereinafter, the present application scheme will be mainly explained by taking the electronic device being a mobile phone as an example.

[0086] Referring to FIG6 , a hardware structure diagram of an electronic device provided in an embodiment of the present application is shown. As shown in FIG6 , taking a mobile phone 600 as an example, the electronic device may include a processor 610, an external memory interface 620, an internal memory 621, a universal serial bus (USB) interface 630, a charging management module 640, a power management module 641, a battery 642, an antenna 1, an antenna 2, a mobile communication module 650, a wireless communication module 660, an audio module 670, a speaker 670A, a receiver 670B, a microphone 670C, an earphone jack 670D, a sensor module 680, a button 690, a motor 691, an indicator 692, a camera 693, a display 694, and a subscriber identification module (SIM) card interface 695, etc.

[0087] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on mobile phone 600. In other embodiments, mobile phone 600 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The components shown in the illustrations may be implemented in hardware, software, or a combination of software and hardware.

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

[0089] The charging management module 640 is configured to receive charging input from a charger. The charger can be either a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 640 can receive charging input from the wired charger via the USB interface 630. In some wireless charging embodiments, the charging management module 640 can receive wireless charging input via the wireless charging coil of the mobile phone 600. While charging the battery 642, the charging management module 640 can also provide power to the mobile phone 600 via the power management module 641.

[0090] The power management module 641 is used to connect the battery 642, the charging management module 640, and the processor 610. The power management module 641 receives input from the battery 642 and / or the charging management module 640 and provides power to the processor 610, the internal memory 621, the external memory, the display 694, the camera 693, and the wireless communication module 660. The power management module 641 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module 641 can also be set in the processor 610. In other embodiments, the power management module 641 and the charging management module 640 can also be set in the same device.

[0091] The wireless communication function of the mobile phone 600 can be implemented through antenna 1, antenna 2, mobile communication module 650, wireless communication module 660, modem processor and baseband processor.

[0092] Display screen 694 is used to display images, videos, etc. In some embodiments, display screen 694 can be used to display dynamically changing interface content, such as the desktop animation shown in Figure 1. Display screen 694 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), Miniled, MicroLed, Micro-oLed, quantum dot light-emitting diodes (QLED), etc.

[0093] Mobile phone 600 implements display functionality through a GPU, display screen 694, and an application processor. The GPU is a microprocessor for image processing that connects display screen 694 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 610 may include one or more GPUs that execute program instructions to generate or modify display information.

[0094] Mobile phone 600 can implement camera functions through an ISP, camera 693, video codec, GPU, display 694, and application processor. The ISP processes data fed back by camera 693. Camera 693 is used to capture still images or video. The lens generates an optical image of an object and projects it onto a photosensitive element. In some embodiments, mobile phone 600 may include one or N cameras 693, where N is a positive integer greater than one.

[0095] The external memory interface 620 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile phone 600. The external memory card communicates with the processor 610 via the external memory interface 620 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0096] The internal memory 621 can be used to store computer executable program codes, which include instructions. The processor 610 executes the instructions stored in the internal memory 621 to execute various functional applications and data processing of the mobile phone 600.

[0097] The mobile phone 600 can implement audio functions such as music playback and recording through the audio module 670, speaker 670A, receiver 670B, microphone 670C, headphone jack 670D, and application processor.

[0098] The buttons 690 include a power button (also called a power button), a volume button, etc. The button 690 can be a mechanical button. It can also be a touch button. The mobile phone 600 can receive key input and generate key signal input related to the user settings and function control of the mobile phone 600. The motor 691 can generate a vibration prompt. The motor 691 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback. The indicator 692 can be an indicator light, which can be used to indicate the charging status, power changes, messages, missed calls, notifications, etc. The SIM card interface 695 is used to connect a SIM card.

[0099] In the embodiment of the present application, the software system of the mobile phone 600 can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a microservice architecture or a cloud architecture. The following embodiment will mainly take the Android system with a layered architecture as an example to illustrate the software architecture of the mobile phone 600.

[0100] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other through software interfaces. In some embodiments, as shown in Figure 7 , the Android system can be divided into six layers: applications, framework, Java Native Interface (JNI), native, hardware abstraction layer (HAL), and kernel.

[0101] Among them, applications such as calls, memos, desktop, browser, contacts, camera, gallery, calendar, etc. can be installed in the application layer. Figure 7 only shows the desktop application (Launcher). These applications basically need to display their application interfaces through the display screen of the mobile phone 600. For example, the Launcher needs to display the application icons on the desktop 101, desktop 103-desktop 107 shown in Figure 1 through the display screen, as well as display the corresponding dynamic effects of the desktop 103-desktop 107 shown in Figure 1.

[0102] The framework layer provides the application layer with an application programming interface (API) and programming framework. This layer includes the display rendering module (Choreographer) and the marking module (AnimationSmooth). AnimationSmooth allows applications to save the on / off state of rendering multiple consecutive frames. The on / off state indicates that multiple consecutive frames are being rendered, while the off state indicates that rendering has stopped.

[0103] Choreographer can be used by applications to request vSync signals from the SF. In other words, Application 1 needs to use Choreographer to request vSync signals from the SF. In this article, when Application 1 calls the requestNextVsync or setVsyncRate interfaces to request vSync signals from the SF, it is actually Choreographer calling the requestNextVsync or setVsyncRate interfaces to request vSync signals from the SF. Furthermore, when Application 1 calls the setVsyncRate interface to cancel vSync signals from the SF, it is actually Choreographer calling the setVsyncRate interface to cancel vSync signals from the SF.

[0104] Furthermore, Choreographer can be used by applications to implement rendering. In other words, Application 1 needs to use Choreographer for rendering. Therefore, in this article, SF distributes vSync signals to Application 1, triggering Application 1 to render. In essence, SF distributes vSync signals to Choreographer, triggering Choreographer to render.

[0105] The local layer provides various services to the upper layer (such as the framework layer). The local layer includes SF, which can be used for synthesis and display, as well as refresh rate control. Among them, refresh rate control means: by distributing vSync signals to applications, controlling the application to start rendering after the display is refreshed once. The local layer includes SF's requestNextVsync interface and setVsyncRate interface, both of which can implement vSync signal requests. Among them, the requestNextVsync interface can implement SF distributing a vSync signal every time a vSync signal is requested. The setVsyncRate interface can implement SF distributing a vSync signal periodically every time a vSync signal is requested.

[0106] It's important to note that the framework layer is typically written in Java, so it can also be called the Java layer. The native layer is written in C++ / C, so it can also be called the C++ / C layer. The Java Native Interface layer serves as a bridge between the framework and native layers, connecting them and enabling mutual access.

[0107] The Java native interface layer includes an interface open to Java, so that the framework layer can call the services provided by the native layer through the interface. In an embodiment of the present application, it is necessary to call the setVsyncRate interface of SF to request a vSync signal from SF, and the setVsyncRate interface in SF is only an interface in the native layer, which does not open an interface to Java. Based on this, in some embodiments, it is necessary to add a new interface in the framework layer and the Java native interface layer respectively, such as the first interface and the second interface in Figure 7. Through the first interface, the second interface and the setVsyncRate interface, the path between the Choreographer in the framework layer and the SF in the native layer is opened, so that the application can call the setVsyncRate interface to request a vSync signal from SF.

[0108] The hardware abstraction layer encapsulates the underlying hardware driver and provides a general interface for calling the driver to drive the corresponding hardware. The hardware abstraction layer includes the hardware composer (HWC). HWC can be combined with the SF to complete the compositing process. SF can use OpenGL ES to synthesize layers, but this synthesis requires and consumes GPU resources. HWC, on the other hand, uses hardware devices to perform layer synthesis, which can reduce the synthesis pressure on the GPU.

[0109] The kernel layer includes drivers that drive hardware operations, such as display drivers. Display drivers are used to drive the display screen and transmit image data streams (such as RGB image data streams) from the upper layer (such as the hardware abstraction layer) to the display screen for display (i.e., sending them to the display).

[0110] The method for requesting a vSync signal provided in the embodiment of the present application can be implemented in a mobile phone 600 having the above-mentioned hardware structure and software structure. The following is a brief introduction to the method for requesting a vSync signal provided in the embodiment of the present application in conjunction with the software architecture of the above-mentioned mobile phone 600:

[0111] After Application 1 determines that it needs to render multiple consecutive frames, it can request a vSync signal from the SF through Choreographer by sequentially calling the first interface in the framework layer, the second interface in the Java native interface layer, and the setVsyncRate interface in the native layer. After receiving the vSync signal request from Choreographer by calling the setVsyncRate interface, the SF periodically distributes the vSync signal to Choreographer, thereby periodically triggering Choreographer to render Application 1's images.

[0112] After Application 1 has finished rendering multiple consecutive frames, it can use Choreographer to sequentially call the first, second, and setVsyncRate interfaces to request the SF to cancel the vSync signal. Upon receiving the cancellation request from Choreographer calling the setVsyncRate interface, the SF stops periodically sending vSync signals to Choreographer. This stops periodically triggering Choreographer to render Application 1's images.

[0113] The application 1 may determine whether it needs to render multiple consecutive frames of images based on its own display logic.

[0114] Example 1: Taking the scenario shown in Figure 1 above as an example, after the Launcher detects a user clicking an application icon on the desktop (such as the application icon 102 for a video application), its display logic is to display a desktop animation that zooms from the application icon to the application interface. This desktop animation requires the Launcher to display multiple consecutive dynamic effect frames, i.e., multiple frames of images, to achieve this. Then, after the Launcher detects a user clicking an application icon on the desktop, it can determine that it needs to render multiple consecutive frames of images.

[0115] Example 2, still taking Launcher as an example, after Launcher detects the user's sliding operation on the desktop (such as sliding to the left or right), the desktop will also slide along with the user's sliding operation. And, after the user's sliding operation is completed, the display logic of Launcher is: continue to slide the desktop until a certain screen of the desktop is fully displayed (such as returning to the screen displayed before the sliding operation, or switching to the previous screen, or switching to the next screen). The above process of continuing to slide the desktop until a certain screen of the desktop is fully displayed requires Launcher to display dynamically changing continuous multi-frame images to achieve. Then, after Launcher detects that the user's sliding operation on the desktop is completed, it can be determined that continuous multi-frame images need to be rendered.

[0116] In Example 3, let's take a calendar app as an example. After detecting a user click on a day in the month view, the calendar app's display logic is to display a transition from the month view to the day view, ultimately displaying the day view. This transition requires the calendar app to display multiple, dynamically changing frames. Therefore, after detecting a user click on a day in the month view, the calendar app can determine that multiple frames of images need to be rendered.

[0117] That is, if after the user's touch operation ends, Application 1 needs to display dynamically changing, continuous multiple-frame images within a short period of time, such as displaying sliding, zooming, or other dynamic effects at intervals of less than 20ms, Application 1 can determine that it needs to render the continuous multiple-frame images. Application 1 can also determine that it needs to end rendering the continuous multiple-frame images after completing the rendering of the multiple-frame images, or before terminating the display of the multiple-frame images, after detecting that Application 1 has exited the foreground, or before terminating the display of the multiple-frame images, after detecting that the display has turned off.

[0118] Normally, before Application 1 needs to render a new frame of image each time, it needs to request a vSync signal through Choreographer to request SF to distribute the vSync signal. And, Choreographer will render the image of Application 1 only after receiving the vSync signal distributed by SF. In the embodiment of the present application, Application 1 only needs to request a vSync signal through Choreographer once after determining that it needs to render multiple consecutive frames of images; and after determining that it has finished rendering multiple consecutive frames of images, it requests to cancel the vSync signal through Choreographer. In other words, even if it is necessary to render multiple consecutive frames of images, it only needs to request a vSync signal through Choreographer once, and there is no need to request a vSync signal through Choreographer every time before rendering a frame of image.

[0119] Referring to FIG. 8 , in some embodiments, when multiple consecutive frames of images need to be rendered, a specific implementation of requesting a vSync signal only once through Choreographer includes:

[0120] S801: Application 1 determines that multiple consecutive frames of images need to be rendered.

[0121] S802: When it is necessary to render a first frame of multiple frames (also referred to as a first image), application 1 requests a vSync signal from Choreographer.

[0122] When Application 1 needs to render any frame of image, it first requests a vSync signal from Choreographer to render the frame (e.g., the first image). This triggers Choreographer to further request a vSync signal from the SF. For example, Application 1 can call the scheduleVsyncLocked interface of Choreographer to trigger Choreographer to request a vSync signal from the SF.

[0123] For the convenience of explanation, the message sent by application 1 to Choreographer to request a vSync signal may be referred to as a first message.

[0124] S803 , Choreographer calls the setVsyncRate interface to request a vSync signal from SF.

[0125] That is, after Application 1 determines to render multiple frames, Choreographer calls the setVsyncRate interface to request a vSync signal from the SF when it first receives a vSync signal request from Application 1. That is, when requesting to render the first frame of the multi-frame image, the setVsyncRate interface is called to request a vSync signal from the SF. Therefore, time t1 in Figure 5 may be the time when the first frame of the multi-frame image is requested to be rendered.

[0126] For example, when Choreographer calls the first interface, the second interface, and the setVsyncRate interface, the parameter carried is the first parameter, which is used to indicate the request for the vSync signal. For example, if the first parameter is 1, the call to the setVsyncRate interface is specifically setVsyncRate(1), indicating that the setVsyncRate interface is called to request the vSync signal.

[0127] S804: The SF update request status is set to periodic request, and the initial value of the request status in the SF is unrequested.

[0128] In this embodiment, the request status further includes a periodic request. The request status is a periodic request, which can instruct the SF to periodically distribute the vSync signal to the Choreographer.

[0129] Exemplarily, the request status and its state transition process are shown in Figure 9. The request status includes unrequested (such as none), requested (such as single) and periodic request (such as period). If the request status is unrequested, it indicates that there is no need to distribute the vSync signal to application 1. If the request status is requested, it indicates that a vSync signal needs to be distributed to application 1 once. If the request status is periodic request, it indicates that a vSync signal needs to be distributed to application 1 periodically. The initial value of the request status is unrequested. When the request status is unrequested, Choreographer calls the requestNextVsync interface to request a vSync signal from SF, and the request status will be updated to requested (see the relevant description in Figure 5 above). When the request status is requested, after SF distributes a vSync signal to application 1 once, the request status will be updated to unrequested (see the relevant description in Figure 5 above). When the request status is unrequested, Choreographer calls the setVsyncRate interface to request the vSync signal from SF (such as setVsyncRate(1)), and the request status will be updated to periodic request, as described in S803-S804.

[0130] It should be noted that the request status in this article refers to application 1. In fact, the request status of each application is maintained in SF. The request status of each application can indicate the demand of the corresponding application for vSync signals.

[0131] In this embodiment, when the first frame of a multi-frame image needs to be rendered, the setVsyncRate interface is called to request a vSync signal from the SF. This allows the SF to promptly update the request status to a periodic request after determining that multiple frames need to be rendered. Subsequently, the SF can periodically distribute vSync signals to trigger the sequential completion of the rendering of multiple frames.

[0132] S805: The display screen sends a vSync signal to the SF.

[0133] When the display completes a refresh, it sends a vSync signal to SF.

[0134] S806 : When the request status is a periodic request, the SF distributes a vSync signal to the Choreographer.

[0135] It should be noted that, referring to Figure 9, if the request status is periodic, after the SF sends the vSync signal to the Choreographer, it does not update the request status to unrequested, but instead maintains the periodic request status. This allows the SF to continue sending the vSync signal to the Choreographer only after receiving it, thus achieving periodic delivery.

[0136] After receiving the vSync signal, Choreographer can render the first frame of multiple frames, then send it to SF for synthesis, and finally send it for display. I will not go into details here.

[0137] S807 : When it is necessary to render the second frame of the multi-frame image, the application 1 requests a vSync signal from the Choreographer.

[0138] After the aforementioned S802-S804, SF has updated the request status to a periodic request. Subsequently, SF can periodically distribute vSync signals to trigger the rendering of multiple frames of images in sequence. Therefore, when requesting to render an image other than the first frame of a multi-frame image (also called the second image), even if application 1 requests a vSync signal from Choreographer, Choreographer does not need to repeatedly request a vSync signal from SF, such as calling the setVsyncRate interface to request a vSync signal from SF. In this way, it is possible to request a vSync signal only once through Choreographer when rendering multiple consecutive frames of images.

[0139] For the convenience of explanation, the moment when rendering of any frame image except the first frame image among the multiple frames of images is requested may be referred to as the third moment.

[0140] S808: The display screen sends a vSync signal to the SF.

[0141] After the display completes one more refresh, it can display the image rendered by Choreographer after S806, and then send it to SF for synthesis, and finally send it to the display, and send a vSync signal to SF.

[0142] S809: When the request status is a periodic request, distribute a vSync signal to the Choreographer.

[0143] After receiving the vSync signal, Choreographer can render the second frame of the multi-frame image, then send it to SF for synthesis, and finally send it for display. I will not go into details here.

[0144] After that, as long as the request status remains a periodic request, after the display sends a vSync signal to SF, SF will continue to distribute vSync signals to Choreographer, and Choreographer can continue to render the third frame image, the fourth frame image... in the multi-frame image.

[0145] S810 , application 1 determines to end rendering of multiple consecutive frames of images.

[0146] S811 . When the first frame of a plurality of frames of images needs to be rendered, application 1 requests a vSync signal from Choreographer.

[0147] After multiple frames of image rendering are completed, when a new frame of image needs to be rendered (i.e., the first frame of image after multiple frames of image, also called the third image), application 1 will also request a vSync signal from Choreographer to request rendering of the new frame of image.

[0148] S812. Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal.

[0149] In this embodiment, after completing the rendering of multiple frames, when Choreographer receives the first vSync signal request from Application 1, it first calls the setVsyncRate interface to request the SF to cancel the vSync signal. That is, when requesting the first frame after rendering multiple frames, the setVsyncRate interface is called to request the SF to cancel the vSync signal. Therefore, time t2 in FIG5 may be the time of the first frame after the request for rendering multiple frames.

[0150] For example, when Choreographer calls the first interface, the second interface, and the setVsyncRate interface, the parameter carried is the second parameter, which is used to indicate a request to cancel the vSync signal. For example, if the second parameter is 0, the call to the setVsyncRate interface is specifically setVsyncRate(0), indicating that the call to the setVsyncRate interface requests to cancel the vSync signal.

[0151] S813: The SF update request status is not requested.

[0152] Continuing to refer to FIG9 , when the request status is periodic request, Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal (eg, setVsyncRate(0)), and the request status is updated to not requested.

[0153] After the request status is updated to not requested, the subsequent SF will not continue to periodically distribute vSync signals after receiving the vSync signal.

[0154] In this embodiment, after multiple frames have been rendered and a new frame needs to be rendered, the setVsyncRate interface is called to request the SF to cancel the vSync signal. This allows the SF to promptly update the request status to "not requested" after the multiple frames have been rendered. Subsequently, the SF will not periodically issue vSync signals, saving resources.

[0155] The above embodiment primarily uses a cycle of 1. Specifically, when Choreographer calls the setVsyncRate interface to request a vSync signal from the SF, it carries a parameter indicating a cycle of 1, such as setVsyncRate(1). The 1 in parentheses indicates a cycle of 1. Then, each time the SF receives a vSync signal, it sends a vSync signal to the Choreographer. Of course, the cycle can also be 2, 3, 4, etc. When Choreographer calls the setVsyncRate interface to request a vSync signal from the SF, it carries a parameter indicating a cycle of n, such as setVsyncRate(n). The n in parentheses indicates a cycle of n. If the cycle is 2, the SF sends a vSync signal to the Choreographer every two vSync signals it receives. If the cycle is 3, the SF sends a vSync signal to the Choreographer every three vSync signals it receives, etc.

[0156] During the use of mobile phone 600, there are numerous scenarios where rendering multiple consecutive frames of images is unnecessary. For example, the timer function in a clock application typically updates the countdown in seconds. For example, if the countdown is 15 minutes and the current display is 15:00, the next display will be 14:59 in 1 second. This 1 second is sufficient for the user to exit the clock application in the foreground or to turn off the screen. In other words, the clock application cannot predict whether it will need to continue displaying the countdown image, such as displaying images corresponding to 14:59, 14:58, 14:57, and so on. Clearly, the timer function of a clock application does not fall within the scope of scenarios where rendering multiple consecutive frames of images is necessary. In these scenarios, the application typically only needs to render a single frame of image when certain conditions are met. For example, using the timer function in the clock application as an example, the clock application only needs to render a new countdown frame every 1 second. For another example, using a calculator application as an example, the calculator application only needs to render a new frame of image when it detects a user tapping a number or symbol on the calculator keyboard.

[0157] In other words, in these scenarios, if the aforementioned periodic distribution method is used, the application needs to call the setVsyncRate interface to request the SF vSync signal before rendering each new frame, triggering the SF to distribute the vSync signal from the display to the application. Furthermore, after the new frame is rendered, the application needs to call the setVsyncRate interface to request the SF to cancel the vSync signal, triggering the SF to stop distributing the vSync signal from the display to the application. In other words, the setVsyncRate interface needs to be called twice to render a single frame, which obviously results in a waste of resources.

[0158] Based on this, in some embodiments, in scenarios where multiple consecutive frames of images need to be rendered, the setVsyncRate interface is called to request a vSync signal from SF; in scenarios where multiple consecutive frames of images do not need to be rendered, the requestNextVsync interface is called to request a vSync signal from SF.

[0159] In this embodiment, application 1 can record the switch state (also referred to as the first switch state) of whether it is necessary to render multiple consecutive frames of images. The switch state includes an on state (such as true) and an off state (such as false). Among them, the initial value of the switch state is the off state. If the switch state is off, it indicates that it is not necessary to render multiple consecutive frames of images. If the switch state is on, it indicates that it is necessary to render multiple consecutive frames of images. When application 1 needs to render any frame of image, after requesting the vSync signal from Choreographer, Choreographer can first query the switch state, and call the requestNextVsync interface or the setVsyncRate interface to request the vSync signal from SF according to the switch state.

[0160] 10 , taking Application 1 storing the switch state of AnimationSmooth in the framework layer shown in FIG. 7 as an example, the method for requesting a vSync signal in this embodiment further includes S1001 to S1007 before S801 in FIG. 8 :

[0161] S1001 : Before determining to render multiple consecutive frames of images, when it is necessary to render images, application 1 requests a vSync signal from Choreographer.

[0162] S1002. Choreographer queries the switch state from AnimationSmooth. The initial value of the switch state in AnimationSmooth is the off state.

[0163] S1003 : Choreographer checks that the switch status is off, and calls the requestNextVsync interface to request a vSync signal from SF.

[0164] In this embodiment, before requesting a vSync signal, Choreographer first queries the on / off status of AnimationSmooth. If it is off, it indicates that there is no need to render multiple consecutive frames. Therefore, Choreographer can call the requestNextVsync API to request a vSync signal. This achieves a one-time vSync signal request and one-time vSync signal delivery.

[0165] S1004: The SF update request status is "requested", and the initial value of the request status of application 1 in the SF is "not requested".

[0166] S1005: The display screen sends a vSync signal to the SF.

[0167] S1006 : When the request status is "requested", the SF distributes a vSync signal to the Choreographer.

[0168] After receiving the vSync signal, Choreographer can start rendering, then send it to SF for synthesis, and finally send it for display.

[0169] S1007: The SF update request status is not requested.

[0170] After the above S1001-S1007, before rendering multiple consecutive frames of images, for one frame of image, it is only necessary to call the requestNextVsync interface to request a vSync signal from SF once. SF can then distribute a vSync signal to trigger Choreographer to complete the rendering without requesting a vSync signal and requesting to cancel the vSync signal, thereby reducing cross-process communication and saving resources.

[0171] It should be noted that the aforementioned S1001-S1007 only describes the processing of rendering one frame of image before determining to render multiple consecutive frames of image. In practice, before determining that multiple consecutive frames of image need to be rendered, there may be at least two frames of image that need to be rendered, and each frame of image can be processed using the above-mentioned S1001-S1007 process.

[0172] Continuing with FIG10 , after application 1 determines that multiple consecutive frames of images need to be rendered, the embodiment differs from the embodiment shown in FIG8 in that: after S801, steps S1008 and S1009 are further included; after application 1 requests a vSync signal from Choreographer, steps S1010 and S1011 are further included to query the on / off status of AnimationSmooth; and S803 is specifically S803a:

[0173] S801: Application 1 determines that multiple consecutive frames of images need to be rendered.

[0174] S1008 , Application 1 triggers AnimationSmooth to update the switch status.

[0175] S1009. AnimationSmooth updates the switch state to on.

[0176] In this embodiment, when the application 1 determines that it needs to render multiple consecutive image frames, it first needs to update the switch state in AnimationSmooth to the on state to indicate that it needs to render multiple consecutive image frames.

[0177] S802 : When the first frame of multiple frames needs to be rendered, application 1 requests a vSync signal from Choreographer.

[0178] S1010. Choreographer queries the switch status from AnimationSmooth.

[0179] S803a. Choreographer checks that the switch status is on and calls the setVsyncRate interface to request a vSync signal.

[0180] In this embodiment, before requesting the vSync signal, Choreographer first queries the switch status of AnimationSmooth. If the query shows that it is on, it means that there is a need to render multiple consecutive frames of images. Therefore, Choreographer can call the setVsyncRate interface to request the vSync signal.

[0181] S804: The SF update request status is a periodic request.

[0182] S805: The display screen sends a vSync signal to the SF.

[0183] S806 : When the request status is a periodic request, the SF distributes a vSync signal to the Choreographer.

[0184] S807 : When it is necessary to render the second frame of the multi-frame image, the application 1 requests a vSync signal from the Choreographer.

[0185] S1011. Choreographer queries the switch status from AnimationSmooth.

[0186] Similarly, before requesting the vSync signal, Choreographer first queries the switch status in AnimationSmooth. If it is found to be on, it means that there is a need to render multiple consecutive frames of images. However, after the aforementioned S802, S1010, S803a and S804, SF has updated the request status to a periodic request. Subsequently, SF can periodically distribute vSync signals to trigger the rendering of multiple frames of images in sequence. Therefore, when it is necessary to render the second frame and subsequent images in multiple frames, even if Application 1 requests the vSync signal, Choreographer will query that the switch status is on, and Choreographer does not need to repeatedly request the vSync signal from SF, such as calling the setVsyncRate interface to request the vSync signal from SF.

[0187] S808: The display screen sends a vSync signal to the SF.

[0188] S809: When the request status is a periodic request, distribute a vSync signal to the Choreographer.

[0189] Continuing with FIG10 , after application 1 determines that rendering of the consecutive multiple frames of images has ended, the embodiment differs from the embodiment shown in FIG8 in that: after S810, steps S1012 and S1013 are further included; after application 1 requests a vSync signal from Choreographer, a step of querying the on / off status of AnimationSmooth is further included, such as S1014; and S812 is specifically S812a:

[0190] S810 , application 1 determines to end rendering of multiple consecutive frames of images.

[0191] S1012. Application 1 triggers AnimationSmooth to update the switch status.

[0192] S1013. AnimationSmooth updates the switch state to off.

[0193] In this embodiment, when the application 1 determines to end rendering of the continuous multiple frames of images, it first needs to update the switch state in AnimationSmooth to the off state to indicate the end of rendering of the continuous multiple frames of images.

[0194] S811 . When the first frame of a plurality of frames of images needs to be rendered, application 1 requests a vSync signal from Choreographer.

[0195] S1014. Choreographer queries the switch status from AnimationSmooth.

[0196] S812a: Choreographer queries that the switch status is off, and the previous query found that it was on, and calls the setVsyncRate interface to request to cancel the vSync signal.

[0197] If Choreographer finds the switch is off, it means that there is no need to render multiple frames continuously. If the previous query found it was on, it means that the need to render multiple frames has just ended. At this time, Choreographer calls the setVsyncRate interface to request to cancel the vSync signal.

[0198] S813: The SF update request status is not requested.

[0199] Furthermore, in some embodiments, the switch states can be maintained separately in AnimationSmooth and Choreographer. This allows the setVsyncRate interface to be called to request a vSync signal from the SF in scenarios where multiple consecutive frames need to be rendered, and the requestNextVsync interface to be called to request a vSync signal from the SF in scenarios where multiple consecutive frames do not need to be rendered. Furthermore, the timing of calling the setVsyncRate interface to request a vSync signal from the SF and canceling the vSync signal can be accurately determined. The initial values ​​of the switch states in both AnimationSmooth and Choreographer are off. To distinguish the first switch state, the switch state in Choreographer can be referred to as the second switch state.

[0200] In this embodiment, before requesting the vSync signal, Choreographer needs to first query the switch status in AnimationSmooth, and based on the queried switch status and the local switch status of Choreographer, determine whether to request the vSync signal from SF, and determine to call the setVsyncRate interface or the requestNextVsync interface to request the vSync signal from SF.

[0201] Referring to FIG11 , this embodiment includes the following steps:

[0202] S1001 : Before determining that multiple consecutive frames of images need to be rendered, when images need to be rendered, application 1 requests a vSync signal from Choreographer.

[0203] For the convenience of explanation, the moment of any frame image that needs to be rendered before the rendering of multiple frames of images is requested may be referred to as the fourth moment.

[0204] S1002. Choreographer queries the switch state from AnimationSmooth. The initial value of the switch state in AnimationSmooth is the off state.

[0205] Continuing to refer to FIG11 , S1003 in FIG10 may specifically be as follows S1003a:

[0206] S1003a: The switch status queried by Choreographer and the local switch status of Choreographer are both off, so the requestNextVsync interface is called to request a vSync signal from SF.

[0207] For the sake of convenience, the request for calling the requestNextVsync interface to request a vSync signal to render any frame image before the multiple frames of images may be referred to as a fourth request.

[0208] In this embodiment, before requesting the vSync signal, Choreographer first queries the switch status in AnimationSmooth. If the query shows that it is in the off state, it means that there is currently no need to render multiple consecutive frames of images. Therefore, Choreographer needs to call the requestNextVsync interface to request the vSync signal, thereby requesting a vSync signal once and distributing a vSync signal once. In addition, the local switch status of Choreographer is off, indicating that the need to render multiple consecutive frames of images has not just ended. Therefore, Choreographer does not need to call the requestNextVsync interface to request the cancellation of the vSync signal. Then, when the queried switch status and the local switch status are both off, the requestNextVsync interface can be called to request the vSync signal.

[0209] S1004: The SF update request status is "requested", and the initial value of the request status of application 1 in the SF is "not requested".

[0210] S1005: The display screen sends a vSync signal to the SF.

[0211] S1006 : When the request status is "requested", the SF distributes a vSync signal to the Choreographer.

[0212] S1007: The SF update request status is not requested.

[0213] S801: Application 1 determines that multiple consecutive frames of images need to be rendered.

[0214] S1008 , Application 1 triggers AnimationSmooth to update the switch status.

[0215] S1009. AnimationSmooth updates the switch state to on.

[0216] S802 : When the first frame of multiple frames needs to be rendered, application 1 requests a vSync signal from Choreographer.

[0217] S1010. Choreographer queries the switch status from AnimationSmooth.

[0218] Continuing to refer to FIG11 , S803a in FIG10 further includes the following S1101-S1102:

[0219] S1101: The switch status queried by Choreographer is on, and the local switch status of Choreographer is off. The local switch status of Choreographer is updated to on.

[0220] Update the local switch state of Choreographer to the on state, so that the local switch state of Choreographer is consistent with whether Application 1 needs to render multiple consecutive frames of images. For example, if Application 1 needs to render multiple consecutive frames of images, the local switch state of Choreographer is updated to the on state.

[0221] S1102 : Choreographer calls the setVsyncRate interface to request a vSync signal from SF.

[0222] In this embodiment, before requesting a vSync signal, Choreographer first queries the switch status in AnimationSmooth. If the query indicates that the switch is on, and Choreographer's local switch status was off before the update, this indicates that Application 1 has just switched from not requiring continuous multi-frame rendering to requiring it. Therefore, Choreographer calls the setVsyncRate API to request a vSync signal, triggering the SF to periodically distribute vSync signals. This ensures that a vSync signal is requested once and then distributed periodically by the SF.

[0223] S804: The SF update request status is a periodic request.

[0224] S805: The display screen sends a vSync signal to the SF.

[0225] S806 : When the request status is a periodic request, the SF distributes a vSync signal to the Choreographer.

[0226] S807 : When it is necessary to render the second frame of the multi-frame image, the application 1 requests a vSync signal from the Choreographer.

[0227] S1011. Choreographer queries the switch status from AnimationSmooth.

[0228] Continuing to refer to FIG11 , after S1011 in FIG10 , the following S1103 is further included:

[0229] S1103: If the switch status queried by Choreographer and the local switch status are both on, the vSync signal is not requested.

[0230] The switch status queried by Choreographer is on, indicating that there is a need to render multiple consecutive frames of images. Therefore, Choreographer needs to call the setVsyncRate interface to request a vSync signal. However, the queried switch status is consistent with the local switch status of Choreographer before the update, indicating that Application 1 has not just changed from not needing to render multiple consecutive frames of images to needing to render multiple consecutive frames of images. Previously, Choreographer should have called the setVsyncRate interface to request a vSync signal (such as S1102). Therefore, Choreographer does not need to repeatedly call the setVsyncRate interface to request a vSync signal. Then, when the queried switch status and the local switch status are both on, there is no need to repeatedly call the requestNextVsync interface to request a vSync signal. This avoids repeatedly calling the requestNextVsync interface to request a vSync signal, ensuring that in scenarios where multiple consecutive frames of images need to be rendered, the vSync signal is only requested once by calling the requestNextVsync interface.

[0231] S808: The display screen sends a vSync signal to the SF.

[0232] S809: When the request status is a periodic request, distribute a vSync signal to the Choreographer.

[0233] S810 , application 1 determines to end rendering of multiple consecutive frames of images.

[0234] S1012. Application 1 triggers AnimationSmooth to update the switch status.

[0235] S1013. AnimationSmooth updates the switch state to off.

[0236] S811 . When the first frame of a plurality of frames of images needs to be rendered, application 1 requests a vSync signal from Choreographer.

[0237] S1014. Choreographer queries the switch status from AnimationSmooth.

[0238] Continuing to refer to FIG11 , S812a in FIG10 further includes the following S1104-S1105:

[0239] S1104: The switch state queried by Choreographer is closed, and the local switch state is open. The local open state is updated to closed.

[0240] Update the local switch state of Choreographer to off, so that the local switch state of Choreographer is consistent with whether Application 1 needs to render multiple consecutive frames of images. For example, if Application 1 does not need to render multiple consecutive frames of images, the local switch state of Choreographer is updated to off.

[0241] S1105 , Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal.

[0242] The switch status queried by Choreographer is off, and the local switch status of Choreographer was on before the update, indicating that Application 1 has just changed from needing to render multiple consecutive frames to not needing to render multiple frames. Therefore, Choreographer needs to first call the setVsyncRate API to request to cancel the vSync signal. This prevents SF from continuing to periodically send vSync signals after the need to render multiple consecutive frames has ended. This allows SF to promptly stop periodically sending vSync signals after the need to render multiple consecutive frames has ended.

[0243] S813: The SF update request status is not requested.

[0244] As of S813, the request status is updated from periodic request to unrequested, and SF will no longer periodically distribute vSync signals. However, application 1 currently needs to render the first frame after multiple frames. Therefore, referring to Figure 11, after S813, it is necessary to execute S1106-S1110 to complete the rendering of the next frame after multiple frames:

[0245] S1106 , Choreographer calls the requestNextVsync interface to request a vSync signal from the SF.

[0246] Since the rendering of multiple consecutive frames of images has ended, Choreographer needs to call the requestNextVsync interface to request a vSync signal from SF, so as to request a vSync signal once, and SF will distribute a vSync signal once.

[0247] That is, in this embodiment, after calling the setVsyncRate interface to request the SF to cancel the vSync signal, Choreographer also needs to call the requestNextVsync interface to request the SF to return the vSync signal. For ease of explanation, calling the requestNextVsync interface to request the vSync signal for the first frame after rendering multiple frames is referred to as the third request.

[0248] S1107: The SF update request status is "Requested".

[0249] S1108 : The display screen sends a vSync signal to the SF.

[0250] S1109 : When the request status is "requested", the SF distributes a vSync signal to the Choreographer.

[0251] SF distributes vSync signals to Choreographer, which can trigger Choreographer to render a new frame of image after completing multiple frames of images, and then send it to SF for synthesis and finally display.

[0252] S1110 , SF update request status is not requested.

[0253] It should be noted that the embodiment of FIG11 only describes the processing of one frame of image after multiple frames of image. After that, if there are images that need to be rendered, the process shown in FIG11 can be repeated. This embodiment will not be described in detail.

[0254] In addition, in the embodiment of FIG11 , Choreographer needs to use corresponding methods to handle the four different combinations of the on / off states in AnimationSmooth and Choreographer, including the first method shown in S1003a, the second method shown in S1101-S1102, the third method shown in S1103, and the fourth method shown in S1104-S1105 and S1106. This ensures that the requestNextVsync interface or the setVsyncRate interface are accurately called to request the vSync signal, or the setVsyncRate interface is called to request the cancellation of the vSync signal.

[0255] In other embodiments, different from the fourth method shown in S1104-S1105 and S1106 in Figure 11 above, when the queried switch state is off (i.e., the switch state in AnimationSmooth is off) and the local switch state is on (i.e., the switch state in Choreographer is on), Choreographer first updates the local on state to off, and then directly calls the requestNextVsync interface to request a vSync signal from SF. In this embodiment, the request state can be transferred between periodic request and requested, as shown by the dotted arrow in Figure 9. When the request state is periodic request, Choreographer calls the requestNextVsync interface to request a vSync signal from SF, and the request state is updated to requested. Then, S1107-S1110 can be continued to complete the rendering of a new frame of image after multiple frames of images. That is to say, different from the embodiment shown in Figure 11, S1105 and S813 can be omitted in this embodiment, and the vSync signal can be requested from SF by directly calling the requestNextVsync interface, so that the request status is changed from periodic request to requested, so that the vSync signal can be requested once and distributed once while the periodic distribution is ended.

[0256] In the aforementioned embodiments, after Application 1 determines that it has finished rendering multiple consecutive frames of images, SF stops periodically distributing the vSync signal. In other embodiments, Choreographer may also determine whether to finish rendering multiple consecutive frames of images. In this embodiment, Application 1 may request a vSync signal from Choreographer each time it needs to render any frame of image (also referred to as the fourth image). At this time, Choreographer may record the processing status as an unprocessed state (also referred to as a first mark). The unprocessed state indicates that there is an image that needs to be rendered. Then, when Choreographer receives the vSync signal from SF, it may update the processing status to a processed state. The processed state indicates that there is no image that needs to be rendered.

[0257] In this embodiment, each time Choreographer receives a vSync signal from the SF, it determines whether the processing status is "unprocessed." If the processing status is "unprocessed," indicating that Application 1 has an image to render, Choreographer can be triggered to render the image and update the processing status to "processed." If the processing status is not "unprocessed," indicating that Application 1 does not have an image to render. In other words, the currently received vSync signal is redundant. It should be understood that when requesting a vSync signal from the SF via the requestNextVsync interface, the SF issues a vSync signal once per request and does not issue redundant vSync signals. Therefore, these redundant vSync signals are most likely periodically issued by the SF after the SF requests a vSync signal via the setVsyncRate interface. In this case, Choreographer can determine that the need to render multiple consecutive frames has ended. Choreographer can then call the setVsyncRate interface to request the SF to cancel the vSync signal. Subsequently, the SF can terminate the periodic vSync signal distribution. In this way, Choreographer can promptly trigger the SF to terminate the periodic vSync signal distribution upon detecting redundant vSync signals.

[0258] Referring to FIG. 12 , in this embodiment, after the Choreographer detects redundant vSync signals, S810 and subsequent steps in the embodiment shown in FIG. 11 may be replaced by the processing steps S1201 to S1213 in FIG. 12 :

[0259] S1201: Choreographer receives a vSync signal, but the processing state is not an unprocessed state, and determines to end rendering of multiple consecutive frames of images.

[0260] S1202 : Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal.

[0261] That is, when Choreographer does not have an unprocessed state but receives a vSync signal from SF, it calls the setVsyncRate interface to request SF to cancel the vSync signal. For convenience of explanation, the moment when Choreographer does not have an unprocessed state but receives a vSync signal from SF is also referred to as the second moment.

[0262] S1203: The SF update request status is not requested.

[0263] S1204. Choreographer triggers AnimationSmooth to update the switch status.

[0264] S1205. AnimationSmooth updates the switch state to off.

[0265] S1206: Choreographer updates the switch state to off.

[0266] That is to say, after Choreographer determines that it has finished rendering multiple consecutive frames of images: first, as shown in S1202, Choreographer needs to request SF to cancel the vSync signal, so that SF ends the periodic distribution of vSync signals. Second, as shown in S1204, Choreographer needs to trigger AnimationSmooth to update the switch state to the off state, so that the switch state in AnimationSmooth indicates that Application 1 has finished rendering multiple consecutive frames of images. Third, as shown in S1206, Choreographer updates the local switch state to the off state, so that the local switch state indicates that Application 1 has finished rendering multiple consecutive frames of images. It should be noted that the execution order of the above three aspects is not limited to that shown in Figure 12. In actual implementation, there is no strict restriction on the order of the above three aspects.

[0267] S1207 : When the application 1 needs to render the first frame of image after rendering multiple frames of image, the application 1 requests a vSync signal from the Choreographer.

[0268] S1208. Choreographer queries the switch status.

[0269] S1209: The switch status queried by Choreographer and the local switch status are both off, so the requestNextVsync interface is called to request a vSync signal from SF.

[0270] That is, in this embodiment, for the first frame image after multiple frames of images, Choreographer can directly call the requestNextVsync interface to request the SF for a vSync signal without first calling the setVsyncRate interface to request the SF to cancel the vSync signal.

[0271] S1210: The SF update request status is "Requested".

[0272] S1211. The display sends a vSync signal to the SF.

[0273] S1212. When the request status is "requested", SF distributes the ChoreographervSync signal to .

[0274] S1213: The SF update request status is not requested.

[0275] An embodiment of the present application further provides an electronic device, which may include a memory and one or more processors. The memory and processors are coupled. The memory is configured to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device may perform the functions or steps performed by the mobile phone in the above-described method embodiment.

[0276] An embodiment of the present application also provides a chip system, as shown in Figure 13, the chip system 1300 includes at least one processor 1301 and at least one interface circuit 1302. The processor 1301 and the interface circuit 1302 can be interconnected via lines. For example, the interface circuit 1302 can be used to receive signals from other devices (such as the memory of an electronic device). For another example, the interface circuit 1302 can be used to send signals to other devices (such as the processor 1301). Exemplarily, the interface circuit 1302 can read instructions stored in the memory and send the instructions to the processor 1301. When the instructions are executed by the processor 1301, the electronic device can perform the various steps in the above embodiments. Of course, the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.

[0277] This embodiment further provides a computer storage medium, in which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the image processing method in the above-mentioned embodiment.

[0278] This embodiment further provides a computer program product. When the computer program product is run on a computer, it enables the computer to execute the above-mentioned related steps to implement the image processing method in the above-mentioned embodiment.

[0279] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the chip to execute the image processing method in the above-mentioned method embodiments.

[0280] Among them, the electronic device, computer storage medium, computer program product or chip provided in this embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0281] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned 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.

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

[0283] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0284] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0285] If the integrated unit is implemented in the form of 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 embodiment of the present application is essentially 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, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0286] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit the present application. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present application.

Claims

1. A method for requesting a vSync signal, characterized in that: For an electronic device with a display function, wherein a first application is installed in the electronic device, the method includes: At a first moment, a first application in the electronic device calls a setVsyncRate interface of a window system SF in the electronic device and sends a first request to the SF, where the first request is used to request a vSync signal; In response to the first request, the SF periodically distributes the vSync signal to the first application; At the second moment, the first application calls the setVsyncRate interface and sends a second request to the SF, where the second request is used to request cancellation of the vSync signal. After receiving the second request, the SF stops periodically distributing the vSync signal to the first application.

2. The method according to claim 1, characterized in that The method further comprises: The first application determines that it needs to render multiple consecutive frames of images, the first moment includes a moment of requesting to render a first image, and the first image is a first frame of the multiple frames of images.

3. The method according to claim 2, characterized in that The first application records a first switch state, and the rendering module of the framework layer of the electronic device records a second switch state, and initial values ​​of the first switch state and the second switch state are both closed; After the first application determines that multiple consecutive frames of images need to be rendered, the method further includes: The first application updates the first switch state to an on state; At the first moment, the first application in the electronic device calls the setVsyncRate interface of the window system SF in the electronic device and sends a first request to the SF, including: At the first moment, the first application sends a first message to the rendering module, where the first message is used to request a vSync signal; In response to the first message, and the first switch state is the on state, and the second switch state is the off state, the rendering module calls the setVsyncRate interface to send a first request to the SF.

4. The method according to claim 3, characterized in that The first switch state is the on state, the second switch state is the off state, and the method further includes: The rendering module updates the second switch state to the on state.

5. The method according to claim 4, characterized in that The method further comprises: At a third moment, the first application sends a first message to the rendering module, where the first message is used to request a vSync signal. The third moment is a moment of requesting rendering of a second image, where the second image is any image in the multiple frames of images except the first frame of image. In response to the first message, and the first switch state is the on state, and the second switch state is the on state, the rendering module does not request the vSync signal from the SF.

6. The method according to claim 4 or 5, characterized in that After sending the first request to the SF, the method further includes: The first application determines to end rendering of multiple consecutive frames of images, and the second moment includes a moment of requesting to render a third image. The third image is the first frame of image that the first application needs to render after completing rendering of the multiple frames of images.

7. The method according to claim 6, characterized in that After the first application determines to end rendering of the continuous multiple frames of images, the method further includes: The first application updates the first switch state to the closed state; At the second moment, the first application calls the setVsyncRate interface to send a second request to the SF, including: At the second moment, the first application sends a first message to the rendering module, where the first message is used to request a vSync signal; In response to the first message, and the first switch state is the closed state, and the second switch state is the open state, the rendering module calls the setVsyncRate interface to send a second request to the SF.

8. The method according to claim 7, characterized in that The first switch state is the closed state, the second switch state is the open state, and the method further includes: The rendering module updates the second switch state to the closed state.

9. The method according to claim 7 or 8, characterized in that After sending the second request to the SF, the method further includes: The first application calls the requestNextVsync interface of the SF to send a third request to the SF, where the third request is used to request a vSync signal; In response to the third request, the SF distributes the vSync signal to the first application once.

10. The method according to claim 4 or 5, characterized in that The SF periodically distributes the vSync signal to the first application, including: The SF periodically distributes the vSync signal to the rendering module.

11. The method according to claim 10, characterized in that The method further comprises: When the first application needs to render a fourth image, sending the first message to the rendering module, where the fourth image is any frame image that the first application needs to display, and the fourth image includes the first image or the second image; In response to the first message, the rendering module records a first flag, and deletes the first flag after receiving the vSync signal from the SF; The second moment includes the moment when the rendering module receives the vSync signal from the SF without including the first mark.

12. The method according to claim 11, characterized in that The method further comprises: At the second moment, the rendering module notifies the first application to update the first switch state to the off state, and the rendering module updates the second switch state to the off state.

13. The method according to any one of claims 3 to 12, characterized in that The method further comprises: At a fourth moment, the first application sends a first message to the rendering module, where the first message is used to request a vSync signal; In response to the first message, and both the first switch state and the second switch state are the closed state, the rendering module calls the requestNextVsync interface to send a fourth request to the SF, where the fourth request is used to request a vSync signal.

14. The method according to any one of claims 1 to 13, characterized in that The SF is located in a local layer of the electronic device, and the first application is located in an application layer of the electronic device. Before sending the first request to the SF, the method further includes: Adding a first interface to the framework layer of the electronic device and adding a second interface to the Java native interface layer of the electronic device, wherein the first interface and the second interface are interfaces of the setVsyncRate interface open to Java; The first application calls the setVsyncRate interface, including: The first application calls the setVsyncRate interface through the first interface and the second interface in sequence.

15. The method according to any one of claims 1 to 14, characterized in that The first request includes a period n, where n≥1 and n is an integer; In response to the first request, the SF periodically distributes the vSync signal to the first application, including: In response to the first request, the SF distributes the vSync signal to the first application once after receiving the vSync signal n times.

16. An electronic device, characterized in that: The electronic device includes a memory and a processor, and the memory and the processor are coupled; wherein computer program code is stored in the memory, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the method according to any one of claims 1 to 15.

17. A computer-readable storage medium, characterized in that The method comprises computer instructions, which, when executed on an electronic device, cause the electronic device to execute the method according to any one of claims 1 to 15.

18. A chip system, characterized in that: The chip system is applied to an electronic device including a processor and a memory. The chip system includes one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected through lines. The interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor. The signal includes a computer instruction stored in the memory. When the processor executes the computer instruction, the electronic device executes the method as described in any one of claims 1 to 15.

Images