WO2024055904A1 - 一种请求vSync信号的方法及电子设备 - Google Patents

一种请求vSync信号的方法及电子设备 Download PDF

Info

Publication number
WO2024055904A1
WO2024055904A1 PCT/CN2023/117580 CN2023117580W WO2024055904A1 WO 2024055904 A1 WO2024055904 A1 WO 2024055904A1 CN 2023117580 W CN2023117580 W CN 2023117580W WO 2024055904 A1 WO2024055904 A1 WO 2024055904A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
request
vsync signal
interface
image
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2023/117580
Other languages
English (en)
French (fr)
Inventor
忻振文
孙文涌
陈川福
李美君
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to US18/993,937 priority Critical patent/US20260018147A1/en
Priority to EP23864636.8A priority patent/EP4538875A4/en
Priority to CN202380066090.1A priority patent/CN119856158A/zh
Publication of WO2024055904A1 publication Critical patent/WO2024055904A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/36—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of a graphic pattern, e.g. using an all-points-addressable [APA] memory
    • G09G5/363—Graphics controllers
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/12—Synchronisation between the display unit and other units, e.g. other display units, video-disc players
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/001—Arbitration of resources in a display system, e.g. control of access to frame buffer by video controller and/or main processor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/545—Gui
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2340/00—Aspects of display data processing
    • G09G2340/04—Changes in size, position or resolution of an image
    • G09G2340/0407—Resolution change, inclusive of the use of different resolutions for different screen areas
    • G09G2340/0435—Change or adaptation of the frame rate of the video stream

Definitions

  • 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.
  • the application can request a vertical synchronization (vSync) signal when it needs to display a new frame of images, and the display of the electronic device can Distribute vSync signals to applications that request vSync signals, that is, to applications with rendering requirements.
  • the vSync signal can trigger the application to complete the rendering of a new frame of image, then synthesize it and finally send it to the display.
  • the application with rendering needs is triggered to start rendering a new frame of image, and then synthesize and send it to the display.
  • FPS Frame Per Second
  • the refresh rate is 60 Hertz (HZ)
  • the FPS can be guaranteed not to exceed 60 frames per second.
  • the inventor found during the implementation of the embodiments of the present application that in the prior art, when the load of the electronic device is high, such as when the central processing unit (Central Processing Unit, CPU) is occupied by more than 97%, the application The delay in requesting the vSync signal will be very long. If the application's request for the vSync signal is not received in time, the vSync signal will naturally not be distributed to the application, so that the application cannot be triggered in time to complete the rendering of a new frame of image, resulting in the display being unable to obtain the new frame of image, and ultimately only Can display old images. Especially when it is necessary to display dynamically changing continuous multi-frame images, if the above problems occur, the dynamic change process will be stuck and unsmooth.
  • CPU Central Processing Unit
  • this application provides a method and electronic device for requesting a vSync signal, which can reduce the possibility of lagging and unsmoothness when it is necessary to display dynamically changing continuous multi-frame images.
  • embodiments of the present application provide a method for requesting a vSync signal, which is used in an electronic device with a display function, such as a mobile phone or a tablet, and the first application is installed in the electronic device.
  • 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, where the first request is used to request a vSync signal.
  • the SF periodically distributes the vSync signal to the first application.
  • the first application may receive the vSync signal periodically.
  • the vSync signal can trigger rendering of images.
  • the first application periodically receives the vSync signal and can render images periodically. 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 the dependence on the Binder thread. In this way, in scenes where dynamically changing continuous multi-frame images need to be displayed, the possibility of display lag and unsmoothness can be reduced.
  • the first application calls the setVsyncRate interface and sends a second request to SF.
  • the second request is used to request to cancel the vSync signal.
  • the SF ends periodically distributing the vSync signal to the first application. In this way, after there is no need for the SF to periodically distribute the vSync signal, the SF can be triggered in time to end the periodic distribution of the vSync signal to the first application, thereby avoiding resource waste caused by long-term periodic distribution.
  • the above method further includes: the first application determines that it needs to render multiple consecutive frames of images, the first moment includes the moment of requesting to render the first image, and the first image is the first frame of the multiple frames of images. .
  • the setVsyncRate interface is called to request the vSync signal from SF, so that after it is determined that consecutive multi-frame images need to be rendered, SF can start to periodically distribute the vSync signal in time, triggering in sequence. Complete the rendering of multi-frame images.
  • the first application records the first switch state
  • the rendering module of the frame layer of the electronic device records the second switch state
  • the initial values of the first switch state and the second switch state are both off.
  • the above method further includes: the first application updates the first switch state to an on state, so that the first switch state indicates that continuous multiple frames of images need to be rendered.
  • 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 SF, including: at the first moment, the first application sends a first message to the rendering module. One message is used to request the vSync signal.
  • the rendering module calls the setVsyncRate interface and sends the first request to SF.
  • the rendering module needs to call the setVsyncRate interface to request
  • the vSync signal triggers the SF to periodically distribute the vSync signal in time.
  • the first switch state is an on state
  • the second switch state is an off state.
  • the above method also includes: the rendering module updates the second switch state to the on state, so that the second switch in the rendering module
  • the status may also synchronously indicate that the first application needs to render consecutive multiple frames of images.
  • the above method also includes: at the third moment, the first application does not request the vSync signal from the SF, the third moment is the moment when the second image is requested to be rendered, and the second image is a multi-frame image except Any image other than the first frame.
  • the first application will not repeatedly call the setVsyncRate interface to request the vSync signal from the SF. Therefore, when multiple consecutive frames of images need to be rendered, the vSync signal can be requested only once, reducing cross-process calls.
  • the first application sends a first message to the rendering module, and the first message is used to request a vSync signal.
  • the first switch state is the on state
  • the second switch state is the on state
  • the rendering module does not request the vSync signal from the SF.
  • the first switch state is an on state, indicating that the first application needs to render consecutive multiple frames of images.
  • the second switch state is also on, indicating that the first application has not just changed from not needing to render consecutive multiple frames of images to needing to render consecutive multiple frames of images. Therefore, the rendering module does not need to repeatedly call the setVsyncRate interface to request the vSync signal.
  • the above method also includes: the first application determines to end rendering of consecutive multiple frames of images.
  • the second moment includes the moment when the third image is requested to be rendered.
  • the third image is the first frame image that the first application needs to render after completing the rendering of the multi-frame image.
  • the setVsyncRate interface is called to request SF to cancel the vSync signal, so that after the multi-frame image rendering is completed, SF can promptly end the periodic distribution of the vSync signal, saving resource.
  • the above method further includes: the first application updates the first switch state to a closed state.
  • the first application calls the setVsyncRate interface and sends a second request to SF, including: at the second moment, the first application sends a first message to the rendering module, and the first message is used to request a vSync signal.
  • the rendering module calls the setVsyncRate interface and sends the second request to SF.
  • the rendering module needs to first call the setVsyncRate interface. Request to cancel the vSync signal to avoid SF still periodically distributing vSync signals after finishing the need to render consecutive multiple frames of images.
  • the first switch state is a closed state
  • the second switch state is an on state.
  • the above method also includes: the rendering module updates the second switch state to the closed state, so that the second switch in the rendering module
  • the status may also synchronously indicate that the first application does not need to render consecutive multiple frames of images.
  • the above method further includes: the first application calls the requestNextVsync interface of the SF and sends a third request to the SF, where the third request is used to request a vSync signal.
  • the SF distributes a vSync signal to the first application.
  • the vSync signal can be further requested from the SF, so that the SF can distribute the vSync signal to trigger the first application to render the first frame after multiple frames of images. image. Therefore, after the rendering of consecutive multiple frames of images is completed, the vSync signal is requested once and the vSync signal is distributed once.
  • the SF periodically distributes the vSync signal to the first application, including: the SF periodically distributes the vSync signal to the rendering module. It should be understood that the first application requires the rendering module to implement rendering. If SF distributes the vSync signal to the rendering module, the rendering module can be triggered to complete image rendering of the first application. Therefore, SF distributes the vSync signal to the rendering module, which is equivalent to distributing the vSync signal to the first application.
  • the above method further includes: sending a first message to the rendering module when the first application needs to render a fourth image, where the fourth image is any frame image that the first application needs to display, and the fourth The image includes a first image or a second image.
  • the rendering module records the first mark, and after receiving the vSync signal from the SF, deletes the first mark.
  • the rendering module can determine whether the processing status is unprocessed. If the processing status is the unprocessed status, it indicates that the first application has an image that needs to be rendered, and the rendering module can be triggered to render the image, and the processing status is updated to the processed status.
  • the processing status is not the unprocessed status, it indicates that the first application does not have an image that needs to be rendered. That is, the currently received vSync signal is redundant. It should be understood that if the vSync signal is requested from SF by calling the requestNextVsync interface, SF will request and distribute the vSync signal once and will not distribute redundant vSync signals. Then, the redundant vSync signal is most likely distributed periodically by SF after requesting the vSync signal from SFSF by calling the setVsyncRate interface. The first application requests SF to cancel the vSync signal at the second moment, then the first application The second moment may be the moment when the rendering module receives the vSync signal from SF without including the first mark. In this way, the rendering module can promptly trigger SF to end the periodic distribution of vSync signals after discovering excess vSync signals.
  • the above method further 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 the first switch Both the state and the second switch state indicate the end of rendering consecutive multi-frame images.
  • the above method further includes: at the fourth moment, the first application sends a first message to the rendering module, and the first message is used to request a vSync signal.
  • the rendering module calls the requestNextVsync interface and sends a fourth request to SF, where the fourth request is used to request a vSync signal.
  • the first switch state is off, it means that the first application does not need to render consecutive multiple frames of images. Moreover, the local switch status of the rendering module is off, indicating that the rendering of consecutive multiple frames of images has not just ended. Therefore, the rendering module does not need to call the requestNextVsync interface to request cancellation of the vSync signal. Then, when the first switch state and the second switch state are both off, the requestNextVsync interface can be called to request the vSync signal.
  • 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.
  • the above method further includes: creating a new application in the framework layer of the electronic device.
  • a first interface is added, and a second interface is added in the Java local interface layer of the electronic device.
  • the first interface and the second interface are interfaces open to Java by the setVsyncRate interface.
  • the first application calls the setVsyncRate interface, which includes: the first application calls the setVsyncRate interface through the first interface and the second interface in sequence.
  • the path between the first application and the SF in the local layer is opened, so that the application can call the setVsyncRate interface to request the vSync signal from the SF.
  • the first request includes period n, n ⁇ 1, and n is an integer.
  • 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 every n times after receiving the vSync signal.
  • the first application can flexibly specify the period of vSync signal distribution by SF according to the display requirements.
  • inventions of the present application provide an electronic device.
  • the electronic device includes a memory and a processor, and the memory is coupled to the processor.
  • Computer program code is stored in the memory, and the computer program code includes computer instructions.
  • the electronic device is caused to execute the method of the first aspect and any possible design method thereof.
  • embodiments of the present application provide 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 The circuit and the processor are interconnected through lines; the interface circuit is used to receive signals from the memory of the electronic device and send the signals to the processor, where the signals include 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 manner thereof.
  • the present application provides a computer storage medium that includes computer instructions, When the computer instructions are run on the electronic device, the electronic device is caused to execute the method described in the first aspect and any possible design manner thereof.
  • the present application provides a computer program product, which when the computer program product is run on a computer, causes the computer to execute the method described in the first aspect and any possible design manner thereof.
  • Figure 1 is a schematic interface diagram of a desktop dynamic effect provided by an embodiment of the present application
  • Figure 2 is a schematic diagram of an image processing process provided by an embodiment of the present application.
  • FIG. 3 is a timing diagram of an image processing method provided by an embodiment of the present application.
  • FIG4 is a schematic diagram of another interface of desktop animation provided in an embodiment of the present application.
  • Figure 5 is a schematic diagram of the principle of a method for requesting a vSync signal provided by an embodiment of the present application
  • Figure 6 is a hardware structure diagram of an electronic device provided by an embodiment of the present application.
  • Figure 7 is a software architecture diagram of an electronic device provided by an embodiment of the present application.
  • Figure 8 is a timing diagram of a method for requesting a vSync signal provided by an embodiment of the present application.
  • Figure 9 is a schematic diagram of a state transition of a request state provided by an embodiment of the present application.
  • Figure 10 is a timing diagram of another method of requesting a vSync signal provided by an embodiment of the present application.
  • Figure 11 is a timing diagram of yet another method of requesting a vSync signal provided by an embodiment of the present application.
  • Figure 12 is a timing diagram of yet another method of requesting a vSync signal provided by an embodiment of the present application.
  • Figure 13 is a schematic structural diagram of a chip system provided by an embodiment of the present application.
  • a and/or B can mean: A exists alone, A and B exist simultaneously, and B exists alone, Where A and B can be singular or plural.
  • the character "/" generally indicates that the related objects are in an "or” relationship.
  • the embodiment of the present application provides a method for requesting a vSync signal, which can be used in scenarios where dynamically changing consecutive multiple frames of images need to be displayed.
  • the scenario where dynamically changing continuous multi-frame images need to be displayed specifically refers to the scenario where the application needs to continue to display sliding, zooming and other dynamic effects after the user's touch operation is completed.
  • the mobile phone after the mobile phone detects the user's click operation on the application icon 102 of the video application on the desktop 101 (that is, after the click operation is completed), the mobile phone will display the desktop 103, the desktop 104, the desktop 105, and the desktop 106 in sequence. and dynamically changing animation effects shown on the desktop 107 to transition, and finally display the application interface of the video application (not shown in Figure 1).
  • the scene shown in Figure 1 above is a scene where dynamically changing consecutive multiple frames of images need to be displayed.
  • the display of a frame of image includes three steps: rendering, synthesis and display.
  • the application that generates the image to be displayed performs the rendering step to complete the rendering of the content in each layer of the image to be displayed.
  • the application sends the rendered layer data to the window system (SurfaceFlinger, SF), and SF performs the synthesis steps based on the layer data, completes the layer synthesis, and obtains the image to be processed.
  • SF executes the display sending step and sends the image to be displayed to the display screen for display.
  • numbers 1-4 represent the 1-4th frame of the image
  • the solid line unfilled rectangular box represents the rendering process
  • the dotted line unfilled rectangular box represents the synthesis process
  • the solid line filled rectangular box represents the display process. process.
  • the rendering of other images is triggered by the vSync signal.
  • the display refreshes according to its refresh rate. For example, if the refresh rate of the display screen is 60HZ, that is, it is refreshed 60 times per second, the display screen will be refreshed at a time interval of 1/60s ⁇ 16.67ms.
  • the refresh rate of the display can also be 90Hz, 120Hz, etc.
  • a vSync signal is generated and distributed to the application through SF to trigger the application to start rendering.
  • SF will be synthesized and finally sent to display. In this way, every time the display screen is refreshed, rendering and synthesis of a new image are triggered. This ensures that the FPS will not exceed the refresh rate of the display.
  • the application needs to request the vSync signal from SF after generating rendering requirements to instruct SF to further distribute the vSync signal after receiving the vSync signal from the display, so as to trigger the application with rendering requirements (such as Launcher) to start rendering and meet the rendering requirements. need.
  • rendering requirements such as Launcher
  • the specific implementation from the application generating rendering requirements to finally displaying a frame of image includes:
  • application 1 (also called the first application) can be any application in the electronic device, and image 1 is any frame image that application 1 needs to display.
  • SF can be used to distribute vSync signals to applications with rendering needs (such as application 1), thereby triggering the application (such as application 1) to start rendering.
  • the requestNextVsync interface in SF is used by applications (such as application 1) to request the 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. .
  • Launcher when Launcher determines that it needs to render the first frame of animation corresponding to 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 Launcher. Trigger Launcher to start rendering the first frame of animation.
  • application 1 requests the vSync signal by calling the requestNextVsync interface and has the following characteristics: after application 1 requests the vSync signal once, SF only distributes the vSync signal to application 1 once, thus only triggering application 1 to complete the rendering of image 1. Subsequently, if application 1 needs to continue rendering, such as rendering image 2, image 3, etc., it needs to call the requestNextVsync interface again to request the vSync signal.
  • the request status of application 1 is recorded in the SF, and the request status includes two types: unrequested and requested.
  • the initial value of the request status is Not Requested.
  • SF updates the request status to Requested, as shown in S302 below, to indicate that Application 1 has rendering requirements.
  • the update request status is not requested, as shown in S305 below, to indicate that Application 1 has no rendering requirements.
  • the display screen refreshes the display according to its refresh rate. For example, if the refresh rate of the display screen is 60 Hertz (HZ), that is, it refreshes 60 times per second, the display screen will refresh the display at a time interval of 1/60s ⁇ 16.67ms.
  • HZ Hertz
  • SF After receiving the vSync signal, SF can query the request status of application 1. If the query shows that the request status is Requested, it means that Application 1 has rendering requirements. In this case, SF distributes the vSync signal to Application 1 to trigger Application 1 to start rendering.
  • Application 1 responds to the vSync signal and renders image 1.
  • Application 1 will start rendering each time it receives a vSync signal to keep the application's frame rate consistent with the digital display rate of the display.
  • Application 1 sends the rendered layer data to SF.
  • SF can also be used for compositing, which mainly refers to compositing one or more layers.
  • the display screen displays image 1.
  • application 1 can call SF when it needs to render any frame of image.
  • requestNextVsync interface to request the vSync signal.
  • SF will distribute a vSync signal to application 1, thereby triggering application 1 to complete the rendering of a frame of image.
  • Application 1 needs to continuously render multiple frames of images.
  • Application 1 needs to call the requestNextVsync interface of SF multiple times to request the vSync signal. Take Figure 1 as an example.
  • Application 1 is Launcher.
  • Launcher When Launcher needs to render the first frame of animation corresponding to desktop 103, it needs to call the requestNextVsync interface to request the vSync signal for the first time; Launcher needs to render the second frame of animation corresponding to desktop 104. When the launcher needs to render the fifth frame of animation corresponding to desktop 107, it needs to call the requestNextVsync interface to request the vSync signal for the fifth time.
  • the above application 1 calls the requestNextVsync interface in SF, which is a cross-process call between different processes, and requires the Binder thread in SF to implement the call.
  • the Binder thread has a lower priority.
  • the load of the electronic device is high, such as when the CPU usage is as high as 97% and above, the electronic device usually cannot allocate CPU resources to the Binder thread first to process the requestNextVsync interface call, then the Binder thread only Can always wait for CPU resources.
  • the Binder thread will be in a state of waiting for resources (i.e. Runnable) for a long time and cannot handle the call to the requestNextVsync interface in a timely manner.
  • SF will not receive application 1's request for the vSync signal in time. Subsequently, when SF receives the vSync signal, it will not be distributed to Application 1 and cannot trigger Application 1 to render the image. In the end, only historical images can be displayed on the display screen, but no new frame of images can be displayed. Especially in scenarios that need to display dynamically changing continuous multiple-frame images, application 1 needs to render continuous multiple-frame images, and the Binder thread needs to be frequently used to process calls to the requestNextVsync interface, so the above problems are more likely to exist.
  • the mobile phone can continue to display images according to the process shown in Figure 3, but at this time it is necessary to render the fifth frame of animation, and the Launcher will render the fifth frame of animation, and finally The fifth frame animation corresponding to desktop 403 will be displayed.
  • the display screen continuously displayed the second frame of three frames of animation, and there was a lag, and it directly transitioned from the second frame of animation to the fifth frame of animation, and the transition of the animation was not smooth.
  • embodiments of the present application provide a method for requesting a vSync signal.
  • This method can be applied to scenarios similar to Figure 1 that need to display dynamically changing consecutive multiple frames of images.
  • the corresponding applications need to render consecutive multiple frames. frame image.
  • application 1 determines that it needs to continuously render multiple frames of images, it can call the setVsyncRate interface of SF to request a vSync signal from SF (such as requesting at time t1 in Figure 5).
  • SF After receiving application 1's request for the vSync signal through the setVsyncRate interface, SF periodically distributes the vSync signal to application 1.
  • Application 1 can be triggered periodically to render images.
  • Application 1 can render multiple consecutive frames of images. Then, after application 1 determines that it has finished rendering consecutive multiple frames of images, it can call the setVsyncRate interface of SF to request SF to cancel the vSync signal (such as the request at time t2 in Figure 5). After receiving application 1's request to cancel the vSync signal through the setVsyncRate interface, SF ends periodically distributing the vSync signal to application 1.
  • 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 is called the first request
  • the request to call the setVsyncRate interface will be called the first request.
  • the request to cancel the vSync signal is called the second request.
  • application 1 only needs to request the vSync signal from SF once, and can receive the vSync signal periodically distributed by SF, thereby periodically triggering application 1 to start rendering.
  • SF periodically distributes the vSync signal, thereby periodically triggering application 1 to complete the rendering of the continuous multi-frame images.
  • Application 1 can request to cancel the vSync signal, so that SF ends periodic distribution of vSync signals to Application 1 to avoid resource waste caused by long-term periodic distribution.
  • the Launcher can determine that it needs to render multiple frames shown on the desktop 103-107 Dynamic effects require rendering multiple consecutive frames of images.
  • the Launcher can call the SF's setVsyncRate interface to request the vSync signal from the SF, triggering the SF to periodically distribute the vSync signal to the Launcher.
  • the periodic vSync signal can trigger the Launcher to sequentially render the multi-frame animation effects shown in desktop 103 to desktop 107.
  • the Launcher can determine to end rendering consecutive multi-frame images. In this case, Launcher can call SF's setVsyncRate interface to request SF to cancel the vSync signal, triggering SF to end periodic distribution of vSync signals to Launcher, reducing resource waste.
  • the electronic device in the embodiment of the present application may be a mobile phone, a tablet computer, a desktop, a laptop, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, and a cellular phone.
  • PDAs personal digital assistants
  • AR augmented reality
  • VR virtual reality
  • the electronic device is a mobile phone as an example to illustrate the application solution.
  • the electronic device may include a processor 610, an external memory interface 620, an internal memory 621, a universal serial bus (USB) interface 630, and a charging management module 640 , power management module 641, battery 642, antenna 1, antenna 2, mobile communication module 650, wireless communication module 660, audio module 670, speaker 670A, receiver 670B, microphone 670C, headphone interface 670D, sensor module 680, button 690, motor 691, indicator 692, camera 693, display screen 694, and subscriber identification module (subscriber identification module, SIM) card interface 695, etc.
  • SIM subscriber identification module
  • the structure illustrated in this embodiment does not constitute a specific limitation on the mobile phone 600.
  • the mobile phone 600 may include more or fewer components than shown, or some components may be combined, some components may be separated, or some components may be arranged differently.
  • the components illustrated may be implemented in hardware, software, or a combination of software and hardware.
  • the processor 610 may include one or more processing units.
  • the processor 610 may include an application processor (application processor, AP), a modem processor, a graphics processing unit (GPU), and an image signal processor. (image signal processor, ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and/or neural-network processing unit (NPU) wait.
  • application processor application processor, AP
  • modem processor graphics processing unit
  • GPU graphics processing unit
  • image signal processor image signal processor
  • ISP image signal processor
  • controller memory
  • video codec digital signal processor
  • DSP digital signal processor
  • NPU neural-network processing unit
  • different processing units can be independent devices or integrated in one or more processors.
  • the charge management module 640 is used to receive charging input from the charger.
  • the charger can be a wireless charger or a wired charger.
  • the charging management module 640 may receive charging input from the wired charger through the USB interface 630 .
  • the charging management module 640 may receive wireless charging input through the wireless charging coil of the mobile phone 600 . While the charging management module 640 charges the battery 642, it can also provide power to the mobile phone 600 through the power management module 641.
  • 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 supplies power to the processor 610, internal memory 621, external memory, display screen 694, camera 693, wireless communication module 660, etc.
  • the power management module 641 can also be used to monitor battery capacity, battery cycle times, battery health status (leakage, impedance) and other parameters.
  • the power management module 641 may also be provided in the processor 610.
  • the power management module 641 and the charging management module 640 can also be provided in the same device.
  • the wireless communication function of the mobile phone 600 can be realized through the antenna 1, the antenna 2, the mobile communication module 650, the wireless communication module 660, the modem processor and the baseband processor.
  • the display screen 694 is used to display images, videos, etc. In some embodiments, the display screen 694 can be used to display dynamically changing interface content, such as the desktop animation shown in FIG. 1 .
  • Display 694 includes a display panel.
  • the display panel can use 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 (active-matrix organic light emitting diode).
  • LCD liquid crystal display
  • OLED organic light-emitting diode
  • AMOLED organic light-emitting diode
  • FLED flexible light-emitting diode
  • Miniled MicroLed, Micro-oLed, quantum dot light emitting diode (QLED), etc.
  • the mobile phone 600 implements display functions through the GPU, the display screen 694, and the application processor.
  • the GPU is an image processing microprocessor and is connected to the display screen 694 and the application processor. GPUs are 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 alter display information.
  • the mobile phone 600 can realize the shooting function through the ISP, camera 693, video codec, GPU, display screen 694 and application processor.
  • the ISP is used to process the data fed back by the camera 693.
  • Camera 693 is used to capture still images or video.
  • the object passes through the lens to produce an optical image that is projected onto the photosensitive element.
  • the mobile phone 600 may include 1 or N cameras 693, where N is a positive integer greater than 1.
  • 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 through the external memory interface 620 to implement the data storage function. Such as saving music, videos, etc. files in external memory card.
  • Internal memory 621 may be used to store computer executable program code, which includes instructions.
  • the processor 610 executes instructions stored in the internal memory 621 to execute various functional applications and data processing of the mobile phone 600 .
  • the mobile phone 600 can implement audio functions through the audio module 670, the speaker 670A, the receiver 670B, the microphone 670C, the headphone interface 670D, and the application processor. Such as music playback, recording, etc.
  • the buttons 690 include a power button (also called a power button), a volume button, etc.
  • Key 690 may be a mechanical key. It can also be a touch button.
  • the mobile phone 600 can receive key input and generate key signal input related to user settings and function control of the mobile phone 600 .
  • Motor 691 can produce vibration prompts. Motor 691 can be used to vibrate Dynamic prompts can also be used for touch vibration feedback.
  • the indicator 692 may be an indicator light, which may be used to indicate charging status, power changes, or may be used to indicate messages, missed calls, notifications, etc.
  • the SIM card interface 695 is used to connect a SIM card.
  • the software system of the mobile phone 600 can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture or a cloud architecture.
  • the following embodiments will mainly take the Android system with a layered architecture as an example to illustrate the software architecture of the mobile phone 600 .
  • the layered architecture divides the software into several layers, and each layer has clear roles and division of labor.
  • the layers communicate through software interfaces.
  • the Android system can be divided into six layers, from top to bottom: application layer (applications), framework layer (framework), Java Native Interface layer (Java Native Interface, JNI), Native layer (Native), hardware abstraction layer (HAL) and kernel layer (kernel).
  • applications such as call, memo, desktop, browser, contacts, camera, gallery, and calendar can be installed in the application layer.
  • Only the desktop application (Launcher) is shown in Figure 7 .
  • These applications basically need to display their application interfaces through the display screen of the mobile phone 600 .
  • the Launcher needs to display the desktop 101 shown in Figure 1, the application icons on the desktop 103-desktop 107 through the display screen, and display the corresponding animation effects of the desktop 103-desktop 107 shown in Figure 1.
  • the framework layer provides application programming interface (API) and programming framework for the application layer.
  • the framework layer includes the display rendering module (Choreographer) and the marking module (AnimationSmooth). AnimationSmooth can be used by applications to save the switch state of rendering consecutive multiple frames of images.
  • the switch state includes the on state and the off state. The on state indicates the need to render consecutive multiple frames of images, and the off state indicates the end of rendering continuous multiple frames of images.
  • Choreographer can be used by applications to request vSync signals from SF.
  • Application 1 needs to request the vSync signal from SF through Choreographer.
  • application 1 calls the requestNextVsync interface or setVsyncRate interface to request a vSync signal from SF, which is essentially Choreographer calling the requestNextVsync interface or setVsyncRate interface to request a vSync signal from SF; and application 1 calls the setVsyncRate interface to request SF to cancel the vSync signal, which is essentially Choreographer. Call the setVsyncRate interface to request SF to cancel the vSync signal.
  • Choreographer can be used for application rendering.
  • Application 1 needs to implement rendering through Choreographer.
  • SF distributes the vSync signal to Application 1 and triggers Application 1 rendering.
  • the essence is that SF distributes the vSync signal to Choreographer and triggers Choreographer rendering.
  • 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 compositing and display, as well as refresh rate control.
  • refresh rate control means by distributing a vSync signal to the application, the application is controlled to start rendering after the display screen is refreshed once.
  • the local layer includes SF's requestNextVsync interface and setVsyncRate interface, both of which can implement the request vSync signal.
  • the requestNextVsync interface can implement a vSync signal every time it is requested, and SF distributes a vSync signal once.
  • the setVsyncRate interface can implement a vSync signal every time it is requested, and SF distributes the vSync signal periodically.
  • the framework layer is usually written in Java language, therefore, the framework layer can also be called the Java layer.
  • the local layer is written in C++/C language, therefore, the local layer can also be called C++/C layer.
  • the Java local interface layer is a bridge between the framework layer and the local layer. It is used to open up the framework layer and the local layer so that the framework layer and the local layer can access each other.
  • the Java local interface layer includes an interface open to Java so that the framework layer can call the services provided by the local layer through this interface.
  • it is necessary to call the setVsyncRate interface of SF to request a vSync signal from SF.
  • the setVsyncRate interface in SF is only an interface in the local layer and does not have an open interface to Java. Based on this, in some embodiments, it is necessary to add an interface to the framework layer and the Java local interface layer respectively, such as the first interface and the second interface in Figure 7.
  • the path between Choreographer in the framework layer and SF in the local layer is opened, so that the application can call the setVsyncRate interface to request the vSync signal from SF.
  • the hardware abstraction layer encapsulates the underlying hardware driver and provides a common interface for calling the driver to the upper layer, so that the upper layer can call the driver to drive the corresponding hardware work.
  • the hardware abstraction layer includes the hardware hybrid renderer (Hwcomposer, HWC). HWC can be combined with SF to complete the synthesis process. Among them, SF can use OpenGL ES to synthesize layers, but this synthesis requires occupying and consuming GPU resources. HWC performs layer synthesis through hardware devices, which can reduce the synthesis pressure on the GPU.
  • the kernel layer includes drivers that drive hardware work, such as display drivers.
  • the display driver is used to drive the display screen and transmit the image data stream (such as RGB image data stream) from the upper layer (such as the hardware abstraction layer) to the display screen for display (i.e., send it to the display).
  • image data stream such as RGB image data stream
  • the upper layer such as the hardware abstraction layer
  • the method for requesting a vSync signal provided by the embodiment of the present application can be implemented in the mobile phone 600 having the above hardware structure and software structure.
  • the following is a brief introduction to the method of requesting a vSync signal provided by the embodiment of the present application in conjunction with the above-mentioned software architecture of the mobile phone 600:
  • application 1 After application 1 determines that it needs to render consecutive multiple frames of images, it can use Choreographer to sequentially call the first interface in the framework layer, the second interface in the Java local interface layer, and the setVsyncRate interface in the local layer to request the vSync signal from SF. After receiving Choreographer's request for the vSync signal by calling the setVsyncRate interface, SF periodically distributes the vSync signal to Choreographer, thereby periodically triggering Choreographer to render the image of application 1.
  • application 1 determines to finish rendering consecutive multiple frames of images, it can use Choreographer to sequentially call the first interface, the second interface, and the setVsyncRate interface to request SF to cancel the vSync signal.
  • SF ends periodically distributing the vSync signal to Choreographer. This will no longer trigger Choreographer to render images for application 1 periodically.
  • application 1 can determine whether it needs to render consecutive multiple frames of images based on its own display logic.
  • Example 1 taking the scenario shown in Figure 1 above as an example, after the Launcher detects the user's click operation on an application icon on the desktop (such as the application icon 102 of a video application), the display logic is: the display zooms in from the application icon to the application icon.
  • Desktop animation of the interface This desktop animation requires Launcher to display dynamically changing multiple consecutive frames of animation, that is, multiple frames of images. Then, after the Launcher detects the user's click operation on an application icon on the desktop, it can determine that multiple consecutive frames of images need to be rendered.
  • Example 2 still taking Launcher as an example, after Launcher detects the user's sliding operation on the desktop (such as sliding left or right), the desktop will also slide along with the user's sliding operation. Moreover, after the user's sliding operation is completed, the display logic of Launcher is: continue sliding 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 the Launcher to display dynamically changing consecutive multiple frames of images. to fulfill. Then, after the Launcher detects that the user's sliding operation on the desktop has ended, it can determine that multiple consecutive frames of images need to be rendered.
  • Example 3 take the calendar application as an example. After the calendar application detects the user's click operation on a certain day in the month view, its display logic is: display the transition effect from the month view to the certain day view, and finally display A view of a certain day. This transition effect requires the calendar application to display dynamically changing consecutive multiple frames of images to achieve. Then, after the calendar application detects the user's click operation on a certain day in the month view, it can determine that multiple consecutive frames of images need to be rendered.
  • Application 1 can Determine the need to render multiple consecutive frames of images. After completing the rendering of the multi-frame image, or before ending the display of the multi-frame image, after detecting the exit of application 1 running in the foreground, or before ending the display of the multi-frame image, detecting the display screen information screen, application 1 can determine to end rendering consecutive multiple frames of images.
  • application 1 needs to request the vSync signal through Choreographer to request SF to distribute the vSync signal every time before rendering a new frame of image. Moreover, Choreographer will render the image of application 1 only after receiving the vSync signal distributed by SF.
  • Application 1 only needs to request a vSync signal through Choreographer after determining that it needs to render consecutive multiple frames of images; and, after determining to end rendering consecutive multiple frames of images, request to cancel the vSync signal through Choreographer. In other words, even if you need to render multiple consecutive frames of images, you only need to request the vSync signal through Choreographer once, instead of requesting the vSync signal through Choreographer before rendering a frame of image each time.
  • the specific implementation of requesting the vSync signal only once through Choreographer includes:
  • Application 1 determines that multiple consecutive frames of images need to be rendered.
  • application 1 When application 1 needs to render any frame of image, it first requests the vSync signal from Choreographer to request the rendering of any frame of image (such as the first image). This triggers Choreographer to further request the vSync signal from SF.
  • Application 1 can call Choreographer's scheduleVsyncLocked interface to trigger Choreographer to request a vSync signal from SF.
  • the message sent by application 1 to Choreographer to request the vSync signal may be called the first message.
  • Choreographer calls the setVsyncRate interface to request the vSync signal from SF.
  • Choreographer when Choreographer receives a request for a vSync signal from Application 1 for the first time after Application 1 determines to render multiple frames of images, it will call the setVsyncRate interface to request a vSync signal from SF. That is, when a request is made to render the first frame of a multi-frame image, the setVsyncRate interface is called to request a vSync signal from SF, then time t1 in Figure 5 may be the time when the first frame of the multi-frame image is requested to be rendered.
  • the parameter carried is the first parameter, which is used to indicate the request for a vSync signal.
  • the first parameter is 1, then calling the setVsyncRate interface is specifically setVsyncRate(1), which means calling the setVsyncRate interface to request a vSync signal.
  • the SF update request status is a periodic request, and the initial value of the request status in SF is not requested.
  • the request status further includes periodic requests.
  • the request status is periodic request, which can instruct SF to periodically distribute the vSync signal to Choreographer.
  • the request status and its status transfer process are shown in Figure 9.
  • the request status includes unrequested (such as none), requested (such as single) and periodic request (such as period).
  • the request status is not requested, indicating that there is no need to distribute the vSync signal to application 1.
  • the request status is requested, indicating that a vSync signal needs to be distributed to application 1.
  • the request status is periodic request, indicating that the vSync signal needs to be distributed to application 1 periodically.
  • the initial value of the request status is not requested.
  • 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).
  • request status in this article is for application 1.
  • request status of each application is maintained in SF.
  • the request status of each application can indicate the corresponding application's need for vSync signals.
  • the setVsyncRate interface is called to request the vSync signal from SF, so that after it is determined that consecutive multi-frame images need to be rendered, SF can promptly update the request status to the cycle Sexual request. Subsequently, SF can periodically distribute vSync signals to trigger the rendering of multiple frames of images in sequence.
  • the display screen sends a vSync signal to SF.
  • a vSync signal will be sent to SF.
  • Choreographer After Choreographer receives the vSync signal, it can render the first frame of the multi-frame image, then send it to SF for synthesis, and finally send it to display. I will not go into details here.
  • application 1 requests the vSync signal from Choreographer.
  • SF has updated the request status to a periodic request. Subsequently, SF can periodically distribute the vSync signal to trigger the completion of the rendering of multiple frames of images in sequence. Therefore, when requesting to render images other than the first frame image (which can also be called the second image) in a multi-frame image, even if application 1 requests the vSync signal from Choreographer, Choreographer does not need to repeatedly request the vSync signal from SF. For example, call the setVsyncRate interface to request the vSync signal from SF. In this way, when multiple consecutive frames of images need to be rendered, the vSync signal can be requested only once through Choreographer.
  • the time when rendering of any frame image in the multi-frame images except the first frame image is requested can be called the third time.
  • the display screen sends a vSync signal to SF.
  • Choreographer After Choreographer receives the vSync signal, it can render the second frame of the multi-frame image, then send it to SF for synthesis, and finally send it to display. I will not go into details here.
  • Application 1 determines to end rendering consecutive multiple frames of images.
  • application 1 requests the vSync signal from Choreographer.
  • Application 1 will also request the vSync signal from Choreographer to request the rendering of the A new frame of image.
  • Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal.
  • Choreographer after completing the rendering of multi-frame images, when Choreographer receives a request for a vSync signal from Application 1 for the first time, it first calls the setVsyncRate interface and requests SF to cancel the vSync signal. That is, when the first frame image after multiple frames of images is requested to be rendered, the setVsyncRate interface is called to request SF to cancel the vSync signal. Then the time t2 in Figure 5 may be the time when the first frame image after multiple frames of images is requested to be rendered.
  • the parameters carried by Choreographer when calling the first interface, the second interface, and the setVsyncRate interface are all second parameters, which are used to indicate a request to cancel the vSync signal.
  • the second parameter is 0, then calling the setVsyncRate interface is specifically setVsyncRate(0), which means calling the setVsyncRate interface to request cancellation of the vSync signal.
  • Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal (such as setVsyncRate(0)), and the request status will be updated to not requested.
  • the request status is updated to not requested, after the subsequent SF receives the vSync signal, it will not continue to distribute the vSync signal periodically.
  • the setVsyncRate interface is called to request SF to cancel the vSync signal, so that after the multi-frame image rendering is completed, SF can promptly update the request status to Not requested. Subsequently, SF will not periodically distribute vSync signals, which can save resources.
  • the cycle is mainly explained as 1. That is: when Choreographer calls the setVsyncRate interface to request a vSync signal from SF, it carries a parameter indicating that the period is 1, such as setVsyncRate(1). The 1 in parentheses indicates that the period is 1; then, each time SF receives a vSync signal, it will send it to Choreographer. Distribute vSync signal. Of course, the period can also be 2, 3, 4....
  • Choreographer calls the setVsyncRate interface to request a vSync signal from SF, it carries a parameter indicating the period n, such as setVsyncRate(n).
  • n in parentheses indicates that the period is n.
  • the period is 2
  • the period is 3, after every 3 vSync signals received by SF, SF distributes vSync to Choreographer...
  • the timing function in the clock application As an example. It usually updates the countdown in seconds (s). For example, if the countdown is 15 minutes and the current display is 15:00, then the next time it will display 14:59 after 1s, and 1s It is completely enough for the user to perform the operation of exiting the clock application running in the foreground, or enough for the user to perform the operation of closing the screen. In other words, it is difficult for the clock application to predict whether it needs to continue to display countdown images, such as then displaying images corresponding to 14:59, 14:58, 14:57...
  • the timing function of the clock application does not belong to scenarios that require rendering of consecutive multiple frames of images.
  • the application usually only needs to render one frame of image when certain conditions are met.
  • the clock application only needs to render a new countdown image every 1 second.
  • the calculator application only needs to render a new frame of image after detecting a user's click operation on a number or symbol on the keyboard of the calculator.
  • the application needs to call the setVsyncRate interface to request the vSync signal from SF before rendering a new frame of image each time to trigger SF to distribute the vSync signal from the display. to the application; and, after the new frame of image rendering is completed, the application needs to call the setVsyncRate interface to request SF to cancel the vSync signal to trigger SF to end distributing the vSync signal from the display to the application. That is, the rendering of one frame of image requires calling the setVsyncRate interface twice. This obviously leads to a waste of resources.
  • the setVsyncRate interface is called to request a vSync signal from SF.
  • the requestNextVsync interface is called to request a vSync signal from SF.
  • application 1 may record the switch state (which may also be called the first switch state) of whether to render consecutive multiple frames of images.
  • the switch state includes the on state (if true) and the off state (if false). Among them, the initial value of the switch state is the closed state. If the switch status is off, it indicates that there is no need to render consecutive multiple frames of images. If the switch status is on, it indicates that multiple consecutive frames of images need to be rendered.
  • Choreographer can first query the switch status, and call the requestNextVsync interface or setVsyncRate interface to request the vSync signal from SF based on the switch status.
  • the method of requesting the vSync signal in this embodiment further includes S1001-S1007 before S801 in Figure 8:
  • application 1 Before determining to render consecutive multiple frames of images and when an image needs to be rendered, application 1 requests a vSync signal from Choreographer.
  • Choreographer first queries the switch status in AnimationSmooth before requesting the vSync signal. If it is found to be in the closed state, it means that there is currently no need to render consecutive multiple frames of images. Therefore, Choreographer can call the requestNextVsync interface to request the vSync signal. To achieve the request once vSync signal, distributes a vSync signal once.
  • the display screen sends the vSync signal to SF.
  • Choreographer After Choreographer receives the vSync signal, it can start rendering, then send it to SF for synthesis, and finally send it to display.
  • each frame of image can be processed using the above-mentioned S1001-S1007 process.
  • Application 1 determines that multiple consecutive frames of images need to be rendered.
  • Application 1 triggers AnimationSmooth to update the switch status.
  • application 1 when application 1 determines that it needs to render consecutive multiple frames of images, it first needs to update the switch state in AnimationSmooth to the on state to indicate that consecutive multiple frames of images need to be rendered.
  • application 1 requests the vSync signal from Choreographer.
  • Choreographer first queries the switch status in AnimationSmooth before requesting the vSync signal. If it is found to be in the open state, it means that there is currently a need to render consecutive multiple frames of images. Therefore, Choreographer can call the setVsyncRate interface to request the vSync signal.
  • the SF update request status is a periodic request.
  • the display screen sends a vSync signal to SF.
  • application 1 requests the vSync signal from Choreographer.
  • Choreographer first queries the switch status in AnimationSmooth before requesting the vSync signal. If it is found to be in the open state, it means that there is currently a need to render consecutive multiple frames of images. However, before passing As mentioned in S802, S1010, S803a and S804, SF has updated the request status to a periodic request. Subsequently, SF can periodically distribute the vSync signal to trigger the completion of the rendering of multiple frames of images in sequence. Therefore, when the second frame of the multi-frame image and subsequent images need to be rendered, even if application 1 requests the vSync signal, Choreographer will query that the switch status is on. Choreographer does not need to repeatedly request the vSync signal from SF, such as calling setVsyncRate. The interface requests the vSync signal from SF.
  • the display screen sends a vSync signal to SF.
  • Application 1 determines to end rendering consecutive multiple frames of images.
  • Application 1 triggers AnimationSmooth to update the switch status.
  • application 1 when application 1 determines to end rendering of 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 continuous multiple frames of images.
  • application 1 requests the vSync signal from Choreographer.
  • Choreographer queries that the switch status is off, which means that there is no need to continuously render multiple frames. On this basis, if the previous query is on, it means that the need to render consecutive multiple frames of images has just been completed. At this time, Choreographer calls the setVsyncRate interface to request to cancel the vSync signal.
  • the switch status can be maintained in AnimationSmooth and Choreographer respectively, so that in scenes where continuous multiple frames of images need to be rendered, the setVsyncRate interface can be called to request the vSync signal from SF, and when continuous multiple frames of images do not need to be rendered, the setVsyncRate interface can be called to request vSync signals from SF.
  • call the requestNextVsync interface to request the vSync signal from SF you can also accurately determine the timing of calling the setVsyncRate interface to request the vSync signal from SF and cancel the vSync signal.
  • the initial values of the switch states in AnimationSmooth and Choreographer are both off. In order to distinguish the first switch state, the switch state in Choreographer can be called the second switch state.
  • Choreographer before Choreographer requests the vSync signal, it needs to first query the switch status in AnimationSmooth, and based on the queried switch status and Choreographer's local switch status, determine whether to request the vSync signal from SF, and determine whether to call the setVsyncRate interface or The requestNextVsync interface requests the vSync signal from SF.
  • this embodiment includes the following steps:
  • the time of any frame of image that needs to be rendered before requesting to render multiple frames of images can be called the fourth time.
  • S1003 in the aforementioned Figure 10 can be specifically as follows S1003a:
  • the request of calling the requestNextVsync interface to request the vSync signal to render any frame of image before the multi-frame image can be called the fourth request.
  • Choreographer first queries the switch status in AnimationSmooth before requesting the vSync signal. If the query is in the closed state, it means that there is currently no need to render consecutive multi-frame images. Therefore, Choreographer needs to call the requestNextVsync interface to request the vSync signal, so as to request a vSync signal and distribute a vSync signal once. Moreover, Choreographer's local switch status is off, indicating that the need to render consecutive multiple frames of images has not just ended. Therefore, Choreographer does not need to call the requestNextVsync interface to request 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.
  • the display screen sends the vSync signal to SF.
  • Application 1 determines that multiple consecutive frames of images need to be rendered.
  • Application 1 triggers AnimationSmooth to update the switch status.
  • application 1 requests the vSync signal from Choreographer.
  • S803a in Figure 10 further includes the following S1101-S1102:
  • Choreographer calls the setVsyncRate interface to request the vSync signal from SF.
  • Choreographer first queries the switch status in AnimationSmooth before requesting the vSync signal. The query found that it is in the on state, and the Choreographer's local switch state was off before the update, indicating that application 1 has just changed from not needing to render consecutive multi-frame images to needing to render consecutive multi-frame images. Therefore, Choreographer needs to call the setVsyncRate interface to request the vSync signal. , triggering SF to periodically distribute the vSync signal in time. In this way, the vSync signal is requested once, and SF periodically distributes the vSync signal.
  • the SF update request status is a periodic request.
  • the display screen sends a vSync signal to SF.
  • application 1 requests the vSync signal from Choreographer.
  • the switch status queried by Choreographer is on, indicating that there is currently a need to render consecutive multiple frames of images. Therefore, Choreographer needs to call the setVsyncRate interface to request the vSync signal.
  • 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 consecutive multi-frame images to needing to render consecutive multi-frame images.
  • Choreographer should have called the setVsyncRate interface to request it before.
  • vSync signal (such as S1102), therefore, Choreographer does not need to repeatedly call the setVsyncRate interface to request the vSync signal.
  • the display screen sends a vSync signal to SF.
  • Application 1 determines to end rendering consecutive multiple frames of images.
  • Application 1 triggers AnimationSmooth to update the switch status.
  • application 1 requests the vSync signal from Choreographer.
  • S812a in Figure 10 further includes the following S1104-S1105:
  • Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal.
  • Choreographer needs to call setVsyncRate first. interface to request cancellation of the vSync signal to avoid SF still periodically distributing vSync signals after the need to render consecutive multiple frames of images. In this way, SF can be triggered in time to end the periodic sending of the vSync signal after the need to render consecutive multi-frame images is completed.
  • the request status is updated from periodic request to unrequested, then SF will not continue vSync signals are distributed periodically.
  • application 1 currently needs to render the first frame of image after multiple frames of image, so, referring to FIG. 11 , after S813 , the following S1106 - S1110 need to be executed to complete the rendering of a new frame of image after multiple frames of image:
  • Choreographer calls the requestNextVsync interface to request the vSync signal from SF.
  • Choreographer needs to call the requestNextVsync interface to request a vSync signal from SF to request a vSync signal, and SF distributes a vSync signal.
  • the requestNextVsync interface to request the vSync signal from the SF.
  • the request for calling the requestNextVsync interface to request the vSync signal to render the first frame of images after multiple frames of images can be called the third request.
  • the display screen sends the vSync signal to SF.
  • SF distributes the vSync signal to Choreographer, which can trigger Choreographer to complete the rendering of a new frame of image after multiple frames of images, and then send it to SF for synthesis and finally display.
  • Choreographer needs to use corresponding methods to handle them, including the first method shown in the aforementioned S1003a, S1101 -The second method shown in 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 is called accurately to request the vSync signal, or the setVsyncRate interface is called to request the cancellation of the vSync signal.
  • what is different from the fourth method shown in S1104-S1105 and S1106 in Figure 11 is that when the switch state queried by Choreographer is off (that is, the switch state in AnimationSmooth is off), the local When the switch status is on (that is, the switch status in Choreographer is on), first update the local on status to off, and then directly call the requestNextVsync interface to request the vSync signal from SF.
  • the request status can be transferred between periodic request and requested, as shown by the dotted arrow in Figure 9.
  • Choreographer calls the requestNextVsync interface to request the vSync signal from SF. , the request status will be updated to Requested.
  • SF ends the periodic analysis.
  • Send vSync signal may also determine whether to end rendering multiple consecutive frames of images.
  • application 1 can request a vSync signal from Choreographer every time it needs to render any frame image (also called the fourth image).
  • Choreographer can record the processing status as unprocessed state (also called the fourth image). first mark).
  • the unprocessed status indicates that there are images that need to be rendered.
  • Choreographer receives the vSync signal from SF, the processing status can be updated to the processed status.
  • the Processed status indicates that there are no images to render.
  • Choreographer can determine whether the processing status is an unprocessed status each time after receiving a vSync signal from SF. If the processing status is unprocessed, it indicates that Application 1 has an image that needs to be rendered, and Choreographer can be triggered to render the image and update the processing status to processed. If the processing status is not the unprocessed status, it means that application 1 does not have an image to render. That is, the currently received vSync signal is redundant. It should be understood that if the vSync signal is requested from SF by calling the requestNextVsync interface, SF will request and distribute the vSync signal once and will not distribute redundant vSync signals.
  • the redundant vSync signal is most likely distributed periodically by SF after requesting the vSync signal from SFSF by calling the setVsyncRate interface.
  • Choreographer can determine that the current need to render consecutive multiple frames of images has been completed, and Choreographer can call the setVsyncRate interface to request SF to cancel the vSync signal.
  • SF can end periodic distribution of vSync signals. In this way, Choreographer can promptly trigger SF to end the periodic distribution of vSync signals after discovering redundant vSync signals.
  • Choreographer receives the vSync signal, but the processing status is not the unprocessed status, and it is determined to end rendering consecutive multi-frame images.
  • Choreographer calls the setVsyncRate interface to request SF to cancel the vSync signal.
  • Choreographer when Choreographer does not include the unprocessed status but receives the vSync signal from SF, it calls the setVsyncRate interface to request SF to cancel the vSync signal.
  • the moment when Choreographer does not include the unprocessed state but receives the vSync signal from SF can also be called the second moment.
  • Choreographer determines to end rendering consecutive multiple frames of images: First, as shown in S1202, Choreographer needs to request SF to cancel the vSync signal so that SF ends periodic distribution of vSync signals.
  • Choreographer needs to trigger AnimationSmooth to update the switch state to the off state, so that the switch state in AnimationSmooth instructs Application 1 to end rendering consecutive multiple frames of images.
  • Choreographer updates the local switch state to the off state, so that the local switch state instructs application 1 to end rendering consecutive multiple 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. During actual implementation, the order of the above three aspects is not strictly limited.
  • Application 1 requests the vSync signal from Choreographer when it needs to render the first frame of images after multiple frames.
  • Choreographer can directly call the requestNextVsync interface to request the vSync signal from SF without first calling the setVsyncRate interface to request SF to cancel the vSync signal.
  • the display screen sends the vSync signal to SF.
  • An embodiment of the present application also provides an electronic device, which may include a memory and one or more processors. Memory and processor coupling.
  • the memory is used to store computer program code, which includes computer instructions.
  • the processor executes the computer instructions, the electronic device can perform each function or step performed by the mobile phone in the above method embodiment.
  • 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 may be interconnected by wires.
  • interface circuitry 1302 may be used to receive signals from other devices, such as memory of an electronic device.
  • interface circuit 1302 may be used to send signals to other devices (eg, processor 1301).
  • the interface circuit 1302 can read instructions stored in the memory and send the instructions to the processor 1301.
  • the electronic device can be caused to perform various steps in the above embodiments.
  • the chip system may also include other discrete devices, which are not specifically limited in the embodiments of this application.
  • This embodiment also provides a computer storage medium that stores computer instructions.
  • the computer instructions When the computer instructions are run on an electronic device, the electronic device executes the above related method steps to implement the image processing method in the above embodiment.
  • This embodiment also provides a computer program product.
  • the computer program product When the computer program product is run on a computer, it causes the computer to perform the above related steps to implement the image processing method in the above embodiment.
  • inventions of the present application also provide a device.
  • This device may be a chip, a component or a module.
  • the device may include a connected processor and a memory.
  • the memory is used to store computer execution instructions.
  • the processor can execute computer execution instructions stored in the memory, so that the chip executes the image processing method in each of the above method embodiments.
  • the electronic equipment, computer storage media, computer program products or chips provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the corresponding methods provided above. The beneficial effects of the method will not be repeated here.
  • the disclosed devices and methods can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple divisions. Units or components may be combined or integrated into another device, or some features may be omitted, or not performed.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • the unit described as a separate component may or may not be physically separate.
  • the component shown as a unit may be one physical unit or multiple physical units, that is, it may be located in one place, or it may be distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application can be integrated into one processing unit, each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the above integrated units can be implemented in the form of hardware or software functional units.
  • 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.
  • the technical solutions of the embodiments of the present application are essentially or contribute to the existing technology, or all or part of the technical solution can be embodied in the form of a software product, and the software product is stored in a storage medium , including several instructions to cause a device (which can be a microcontroller, a chip, etc.) or a processor to execute all or part of the steps of the methods of various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Graphics (AREA)
  • Human Computer Interaction (AREA)
  • Digital Computer Display Output (AREA)
  • Controls And Circuits For Display Device (AREA)
  • Telephone Function (AREA)

Abstract

本申请提供一种请求vSync信号的方法及电子设备，涉及图像显示技术领域，在需要显示动态变化的连续多帧图像时，可以降低卡顿、不流畅的可能性。在第一时刻，电子设备中的第一应用调用电子设备中窗口系统SF的setVsyncRate接口，向SF发送第一请求，第一请求用于请求vSync信号。响应于第一请求，SF周期性向第一应用分发vSync信号。在第二时刻，第一应用调用setVsyncRate接口，向SF发送第二请求，第二请求用于请求取消vSync信号，SF在接收到第二请求之后，结束周期性向第一应用分发vSync信号。

Description

一种请求vSync信号的方法及电子设备
本申请要求于2022年9月14日提交国家知识产权局、申请号为202211116851.3、发明名称为“一种请求vSync信号的方法及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及图像显示技术领域，尤其涉及一种请求vSync信号的方法及电子设备。
背景技术
手机、平板等电子设备的显示屏亮屏的情况下，应用在需要显示新一帧图像时，可以请求垂直同步(Vertical Synchronization，vSync)信号，并且电子设备的显示屏在一次刷新完成后，可以将vSync信号分发给请求vSync信号的应用，即分发给有渲染需求的应用。vSync信号可以触发应用完成新一帧图像的渲染，然后经过合成，最终送显。如此，在显示屏刷新一次后，才触发有渲染需求的应用开始渲染新一帧图像，然后合成并送显。从而可以保证画面每秒传输帧数(Frame Per Second，FPS)不会超过显示屏的刷新率。例如，刷新率为60赫兹(HZ)，则可以保证FPS不超过每秒60帧。
然而，发明人在实施本申请实施例的过程中发现，在现有技术中，在电子设备的负载较高时，如中央处理器(Central Processing Unit，CPU)的占用超过97％以上时，应用请求vSync信号的时延会很长。若未及时收到应用对vSync信号的请求，自然就不会将vSync信号分发给该应用，从而无法及时触发应用完成新一帧图像的渲染，导致显示屏无法获得该新一帧图像，最终只能显示旧的图像。尤其在需要显示动态变化的连续多帧图像时，若出现上述问题，则会造成动态变化的过程卡顿、不流畅。
发明内容
有鉴于此，本申请提供了一种请求vSync信号的方法及电子设备，在需要显示动态变化的连续多帧图像时，可以降低卡顿、不流畅的可能性。
第一方面，本申请实施例提供一种请求vSync信号的方法，用于具有显示功能的电子设备，如应用于手机、平板中，电子设备中安装有第一应用。其中，在第一时刻，电子设备中的第一应用调用电子设备中窗口系统SF的setVsyncRate接口，向SF发送第一请求，第一请求用于请求vSync信号。响应于第一请求，SF周期性向第一应用分发vSync信号。
应理解，SF周期性向第一应用分发vSync信号，则第一应用可以周期性的接收到vSync信号。vSync信号可以触发渲染图像。第一应用周期性的接收到vSync信号，则可以周期性的渲染图像。这样，第一应用仅请求一次vSync信号，则可以完成多帧图像的渲染，而无需针对多帧图像请求多次vSync信号。从而可以减少应用进程和SF进程之间的跨进程调用，降低了对Binder线程的依赖。如此，在需要显示动态变化的连续多帧图像的场景中，可以降低出现显示卡顿、不流畅的现象的可能。
并且，在第二时刻，第一应用调用setVsyncRate接口，向SF发送第二请求，第 二请求用于请求取消vSync信号，SF在接收到第二请求之后，结束周期性向第一应用分发vSync信号。如此，可以在不需要SF周期性分发vSync信号后，及时触发SF结束向第一应用周期性分发vSync信号，避免长期周期性分发造成资源浪费。
在一种可能的设计方式中，上述方法还包括：第一应用确定需要渲染连续多帧图像，第一时刻包括请求渲染第一图像的时刻，第一图像为多帧图像中的第一帧图像。如此，在需要渲染多帧图像中的第一帧图像时，则调用setVsyncRate接口向SF请求vSync信号，从而可以在确定需要渲染连续多帧图像后，及时使SF开始周期性分发vSync信号，触发依次完成多帧图像的渲染。
在一种可能的设计方式中，第一应用记录第一开关状态，电子设备的框架层的渲染模块中记录第二开关状态，第一开关状态和第二开关状态的初始值均为关闭状态。在第一应用确定需要渲染连续多帧图像之后，上述方法还包括：第一应用更新第一开关状态为开启状态，使第一开关状态指示需要渲染连续多帧图像。
上述在第一时刻，电子设备中的第一应用调用电子设备中窗口系统SF的setVsyncRate接口，向SF发送第一请求，包括：在第一时刻，第一应用向渲染模块发送第一消息，第一消息用于请求vSync信号。响应于第一消息，且第一开关状态为开启状态，第二开关状态为关闭状态，渲染模块调用setVsyncRate接口，向SF发送第一请求。
其中，第一开关状态为开启状态，第二开关状态为关闭状态，表明第一应用刚从不需要渲染连续多帧图像转变为需要渲染连续多帧图像，因此，渲染模块需要调用setVsyncRate接口来请求vSync信号，及时触发SF周期性分发vSync信号。
在一种可能的设计方式中，第一开关状态为开启状态，第二开关状态为关闭状态，上述方法还包括：渲染模块更新第二开关状态为开启状态，从而使渲染模块中的第二开关状态也可以同步指示第一应用需要渲染连续多帧图像。
在一种可能的设计方式中，上述方法还包括：在第三时刻，第一应用不向SF请求vSync信号，第三时刻为请求渲染第二图像的时刻，第二图像为多帧图像中除第一帧图像之外的任一图像。如此，在需要渲染多帧图像中的第二帧图像以及之后的图像时，第一应用不会重复调用setVsyncRate接口向SF请求vSync信号。从而可以在需要渲染连续多帧图像的情况下，仅请求一次vSync信号，减少跨进程调用。
具体地，在第三时刻，第一应用向渲染模块发送第一消息，第一消息用于请求vSync信号。响应于第一消息，且第一开关状态为开启状态，第二开关状态为开启状态，渲染模块不向SF请求vSync信号。其中，第一开关状态为开启状态，表示第一应用需要渲染连续多帧图像的需求。但是，第二开关状态也为开启状态，表明第一应用并不是刚从不需要渲染连续多帧图像转变为需要渲染连续多帧图像，因此，渲染模块不需要重复调用setVsyncRate接口来请求vSync信号。那么，在第一开关状态为开启状态，第二开关状态为开启状态的情况下，无需重复调用requestNextVsync接口来请求vSync信号。从而可以避免重复调用requestNextVsync接口来请求vSync信号，保证在需要渲染连续多帧图像的场景中，仅通过调用requestNextVsync接口来请求一次vSync信号。
在一种可能的设计方式中，上述方法还包括：第一应用确定结束渲染连续多帧图 像，第二时刻包括请求渲染第三图像的时刻，第三图像为完成多帧图像的渲染后，第一应用需要渲染的第一帧图像。如此，在多帧图像渲染完成后，需要渲染新一帧图像时，则调用setVsyncRate接口向SF请求取消vSync信号，从而可以在多帧图像渲染完成后，及时使SF结束周期性分发vSync信号，节省资源。
在一种可能的设计方式中，在第一应用确定结束渲染连续多帧图像之后，上述方法还包括：第一应用更新第一开关状态为关闭状态。上述在第二时刻，第一应用调用setVsyncRate接口，向SF发送第二请求，包括：在第二时刻，第一应用向渲染模块发送第一消息，第一消息用于请求vSync信号。响应于第一消息，且第一开关状态为关闭状态，第二开关状态为开启状态，渲染模块调用setVsyncRate接口，向SF发送第二请求。
其中，第一开关状态为关闭状态，第二开关状态为开启状态，表明第一应用刚从需要渲染连续多帧图像转变为不需要渲染连续多帧图像，因此，渲染模块需要先调用setVsyncRate接口来请求取消vSync信号，避免在结束渲染连续多帧图像的需求后，SF仍然周期性的分发vSync信号。
在一种可能的设计方式中，第一开关状态为关闭状态，第二开关状态为开启状态，上述方法还包括：渲染模块更新第二开关状态为关闭状态，从而使渲染模块中的第二开关状态也可以同步指示第一应用不需要渲染连续多帧图像。
在一种可能的设计方式中，在向SF发送第二请求之后，上述方法还包括：第一应用调用SF的requestNextVsync接口，向SF发送第三请求，第三请求用于请求vSync信号。响应于第三请求，SF向第一应用分发一次vSync信号。
也就是说，采用本实施例的方法，可以在触发SF结束周期性分发vSync信号后，进一步向SF请求vSync信号，使SF可以分发vSync信号来触发第一应用渲染多帧图像之后的第一帧图像。从而可以在结束渲染连续多帧图像后，请求一次vSync信号，则分发一次vSync信号。
在一种可能的设计方式中，SF周期性向第一应用分发vSync信号，包括：SF周期性向渲染模块分发vSync信号。应理解，第一应用需要渲染模块来实现渲染，SF向渲染模块分发vSync信号，则可以触发渲染模块来完成第一应用的图像渲染。因此，SF向渲染模块分发vSync信号，相当于实现了向第一应用分发vSync信号。
在一种可能的设计方式中，上述方法还包括：在第一应用需要渲染第四图像时，向渲染模块发送第一消息，第四图像是第一应用需要显示的任一帧图像，第四图像包括第一图像或者第二图像。响应于第一消息，渲染模块记录第一标记，并在接收到来自SF的vSync信号后，删除第一标记。渲染模块在每次接收到来自SF的vSync信号后，可以判断处理状态是否为未处理状态。若处理状态为未处理状态，表明第一应用有需要渲染的图像，则可以触发渲染模块渲染该图像，并更新处理状态为已处理状态。若处理状态不是未处理状态，则表明第一应用并没有需要渲染的图像。也就是说，当前接收到的vSync信号是多余的。应理解，若通过调用requestNextVsync接口向SF请求vSync信号，SF是请求一次，分发一次vSync信号，不会分发多余的vSync信号。那么，该多余的vSync信号极有可能是通过调用setVsyncRate接口向SFSF请求vSync信号后，SF周期性分发的。第一应用在第二时刻向SF请求取消vSync信号，则该第 二时刻可以为渲染模块在不包括第一标记的情况下，接收到来自SF的vSync信号的时刻。如此，渲染模块可以在发现多余的vSync信号后，及时触发SF结束周期性分发vSync信号。
在一种可能的设计方式中，上述方法还包括：在第二时刻，渲染模块通知第一应用将第一开关状态更新为关闭状态，渲染模块更新第二开关状态为关闭状态，使第一开关状态和第二开关状态均指示结束渲染连续多帧图像。
在一种可能的设计方式中，上述方法还包括：在第四时刻，第一应用向渲染模块发送第一消息，第一消息用于请求vSync信号。响应于第一消息，且第一开关状态和第二开关状态均为关闭状态，渲染模块调用requestNextVsync接口，向SF发送第四请求，第四请求用于请求vSync信号。
其中，第一开关状态为关闭状态，则表示第一应用不需要渲染连续多帧图像。并且，渲染模块本地的开关状态为关闭状态，表示此时并不是刚结束渲染连续多帧图像。因此，渲染模块无需调用requestNextVsync接口来请求取消vSync信号。那么，在第一开关状态和第二开关状态均为关闭状态的情况下，则可以调用requestNextVsync接口来请求vSync信号。
在一种可能的设计方式中，SF位于电子设备的本地层，第一应用位于电子设备的应用程序层，在向SF发送第一请求之前，上述方法还包括：在电子设备的框架层中新增第一接口，在电子设备的Java本地接口层中新增第二接口，第一接口和第二接口是setVsyncRate接口对Java开放的接口。第一应用调用setVsyncRate接口，包括：第一应用依次经过第一接口和第二接口调用setVsyncRate接口。
也就是说，采用本实施例，通过第一接口、第二接口和setVsyncRate接口，打通第一应用到本地层中的SF之间的通路，使得应用可以调用setVsyncRate接口，实现向SF请求vSync信号。
在一种可能的设计方式中，第一请求中包括周期n，n≥1，n为整数。响应于第一请求，SF周期性向第一应用分发vSync信号，包括：响应于第一请求，SF在每接收到n次vSync信号后，向第一应用分发一次vSync信号。
也就是说，采用本实施例，第一应用可以根据显示需求，灵活指定SF分发vSync信号的周期。
第二方面，本申请实施例提供一种电子设备，电子设备包括存储器和处理器，所述存储器和所述处理器耦合；其中，存储器中存储有计算机程序代码，计算机程序代码包括计算机指令，当计算机指令被处理器执行时，使得电子设备执行如第一方面及其任一种可能的设计方式的方法。
第三方面，本申请实施例提供一种芯片系统，该芯片系统应用于包括显示屏和存储器的电子设备；所述芯片系统包括一个或多个接口电路和一个或多个处理器；所述接口电路和所述处理器通过线路互联；所述接口电路用于从所述电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述电子设备执行如第一方面及其任一种可能的设计方式所述的方法。
第四方面，本申请提供一种计算机存储介质，该计算机存储介质包括计算机指令， 当所述计算机指令在电子设备上运行时，使得电子设备执行如第一方面及其任一种可能的设计方式所述的方法。
第五方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。
可以理解地，上述提供的第二方面所述的电子设备，第三方面所述的芯片系统，第四方面所述的计算机存储介质，第五方面所述的计算机程序产品所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。
附图说明
图1为本申请实施例提供的一种桌面动效的界面示意图；
图2为本申请实施例提供的一种图像处理过程的示意图；
图3为本申请实施例提供的一种图像处理方法的时序图；
图4为本申请实施例提供的另一种桌面动效的界面示意图；
图5为本申请实施例提供的一种请求vSync信号的方法的原理示意图；
图6为本申请实施例提供的电子设备的硬件结构图；
图7为本申请实施例提供的电子设备的软件架构图；
图8为本申请实施例提供的一种请求vSync信号的方法的时序图；
图9为本申请实施例提供的一种请求状态的状态转移示意图；
图10为本申请实施例提供的另一种请求vSync信号的方法的时序图；
图11为本申请实施例提供的又一种请求vSync信号的方法的时序图；
图12为本申请实施例提供的再一种请求vSync信号的方法的时序图；
图13为本申请实施例提供的一种芯片系统的结构示意图。
具体实施方式
下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式，除非其上下文中明确地有相反指示。还应当理解，在本申请以下各实施例中，“至少一个”、“一个或多个”是指一个或两个以上(包含两个)。术语“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。术语“连接”包括直接连接和间接连接，除非另外说明。“第一”、 “第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。
在本申请实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
本申请实施例提供一种请求vSync信号的方法，可用于需要显示动态变化的连续多帧图像的场景。其中，需要显示动态变化的连续多帧图像的场景具体是指在用户的触摸操作结束后、应用需要继续显示滑动、缩放等动效的场景。
示例性的，参见图1，手机在检测到用户对桌面101上视频应用的应用图标102的点击操作后(即点击操作结束后)，会依次显示如桌面103、桌面104、桌面105、桌面106以及桌面107所示的动态变化的动效来过渡，并最终显示视频应用的应用界面(图1中未示出)。上述图1所示的场景即为需要显示动态变化的连续多帧图像的场景。
通常情况下，一帧图像的显示包括渲染、合成以及送显三个步骤。其中，由产生待显示图像的应用执行渲染的步骤，完成待显示图像的各个图层中内容的渲染。然后，应用将渲染得到的图层数据发送给窗口系统(SurfaceFlinger，SF)，由SF基于图层数据执行合成的步骤，完成图层合成，得到待处理图像。再后，SF执行送显的步骤，将待显示图像送往显示屏显示。
与此同时，参见图2，数字1-4表示第1-4帧图像，实线无填充矩形框表示渲染的过程，虚线无填充矩形框表示合成的过程，实线有填充矩形框表示显示的过程。很显然，除第1帧图像之外，其它图像的渲染都是由vSync信号触发的。具体地，显示屏会按照其刷新率来刷新。例如，显示屏的刷新率为60HZ，即每秒刷新60次，则显示屏会以1/60s≈16.67ms的时间间隔刷新。当然，显示屏的刷新率也可以是90Hz、120Hz等。显示屏在完成一次刷新后，会产生vSync信号，并通过SF分发给应用，以触发应用开始渲染。应用渲染完成后，SF再进行合成，最后送显。如此，显示屏每刷新一次后，才触发渲染、合成一帧新图像。从而可以保证FPS不会超过显示屏的刷新率。
在电子设备的使用过程中，不同应用对渲染的需求是不同的。通常情况下，应用是否有渲染的需求，需要应用基于自身的显示逻辑来确定。以图1为例，只有Launcher知道在检测到用户对桌面上应用图标的点击操作后，需要显示桌面103-桌面107对应的动效，相应的，则需要连续渲染该动效包括的多帧图像。例如，桌面103-桌面107依次对应第1帧-第5帧动效，则需要连续渲染5个动效帧。因此，需要应用在产生渲染需求后，向SF请求vSync信号，以指示SF在接收到来自显示屏的vSync信号后进一步分发，从而才能触发有渲染需求的应用(如Launcher)开始渲染，满足渲染的需求。
在一些实施例中，参见图3，从应用产生渲染需求，到最终显示一帧图像的具体实现包括：
S301、应用1在需要渲染图像1时，调用SF的requestNextVsync接口向SF请求vSync信号。
其中，应用1(也可以称为第一应用)可以是电子设备中的任一应用，图像1是应用1需要显示的任一帧图像。SF可用于将vSync信号分发给有渲染需求的应用(如应用1)，从而触发应用(如应用1)开始渲染。SF中的requestNextVsync接口供应用(如应用1)用来请求vSync信号，即供应用(如应用1)请求SF将vSync信号分发给应用(如应用1)，以触发应用(如应用1)开始渲染。
以应用1是Launcher为例，在Launcher确定需要渲染图1所示桌面103对应的第1帧动效时，则可以调用SF的requestNextVsync接口请求vSync信号，即请求SF将vSync信号分发给Launcher，以触发Launcher开始渲染第1帧动效。
在本实施例中，应用1通过调用requestNextVsync接口来请求vSync信号具有如下特性：应用1请求一次vSync信号后，SF仅向应用1分发一次vSync信号，从而只能触发应用1完成图像1的渲染。后续，若应用1需要继续渲染，如渲染图像2、图像3……，则需要再次调用requestNextVsync接口来请求vSync信号。
示例性的，SF中记录有应用1的请求状态，请求状态包括未请求和已请求两种。请求状态的初始值为未请求。SF在接收到应用1对vSync信号的请求后，则更新请求状态为已请求，如下S302所示，以指示应用1有渲染需求。而在SF向应用1分发一次vSync信号后，则更新请求状态为未请求，如下S305所示，以指示应用1没有渲染需求。
S302、SF更新请求状态为已请求。
S303、在一次刷新完成后，显示屏向SF发送vSync信号。
显示屏在每一次刷新完成后，则会向SF发送vSync信号，以指示开始下一帧图像的显示流程，如渲染、合成以及送显。
应理解，显示屏会按照其刷新率来刷新显示。例如，显示屏的刷新率为60赫兹(HZ)，即每秒刷新60次，则显示屏会以1/60s≈16.67ms的时间间隔刷新显示。
S304、在请求状态为已请求的情况下，SF向应用1分发vSync信号。
SF在接收到vSync信号后，可查询应用1的请求状态。若查询到请求状态为已请求，则表示应用1有渲染需求。该情况下，SF则将vSync信号分发给应用1，以触发应用1开始渲染。
应理解，若有多个应用请求vSync信号，则表明多个应用具有渲染需求，SF需要将vSync信号分发给多个应用。
S305、SF更新请求状态为未请求。
S306、应用1响应于vSync信号，渲染图像1。
应用1在每次接收到vSync信号后，才会开始渲染，以使应用的帧率与显示屏的数显率保持一致。
S307、应用1向SF发送渲染后的图层数据。
S308、SF对图像1完成合成处理。
SF还可以用于合成处理，合成处理主要是指将一个或多个图层进行合成。
S309、SF向显示屏发送合成后的图像1。
S310、显示屏显示图像1。
采用本实施例，应用1可以在需要渲染任一帧图像时，通过调用SF的 requestNextVsync接口来请求vSync信号，后续SF则会向应用1分发一次vSync信号，从而触发应用1完成一帧图像的渲染。相应的，在需要显示动态变化的连续多帧图像的场景中，应用1则需要连续渲染多帧图像，相应的，应用1需要连续多次调用SF的requestNextVsync接口来请求vSync信号。以图1为例，应用1为Launcher，Launcher在需要渲染桌面103对应的第1帧动效时，需要调用requestNextVsync接口第一次请求vSync信号；Launcher在需要渲染桌面104对应的第2帧动效时，需要调用requestNextVsync接口第二次请求vSync信号……Launcher在需要渲染桌面107对应的第5帧动效时，需要调用requestNextVsync接口第五次请求vSync信号。
然而，上述应用1调用SF中的requestNextVsync接口，属于不同进程之间的跨进程调用，需要SF中的Binder线程来实现该调用。Binder线程的优先级较低，在电子设备的负载较高时，如CPU占用高达97％及以上时，电子设备通常无法优先为Binder线程分配CPU资源用于处理requestNextVsync接口的调用，则Binder线程只能一直等待CPU资源。从而导致Binder线程会长时间处于等待资源(即Runnable)的状态，无法及时处理requestNextVsync接口的调用。那么，SF也不会及时接收到应用1对vSync信号的请求。后续，当SF接收到vSync信号后，则不会分发给应用1，无法触发应用1渲染图像。最终，显示屏中则只能显示历史的图像，而无法显示新一帧图像。尤其在需要显示动态变化的连续多帧图像的场景中，应用1需要渲染连续多帧图像，则需要频繁使用Binder线程来处理requestNextVsync接口的调用，因此更有可能存在上述问题。
并且，在需要显示动态变化的连续多帧图像的场景中，若无法及时显示新一帧图像，最终会导致动态变化的过程出现显示卡顿、不流畅的现象。如图4所示，在手机的负载正常时，可以按照前述图3所示的流程来显示图像，显示屏中可以依次显示第1帧动效(如桌面401)和第2帧动效(如桌面402a)。此后手机的负载增大，无法按照前述图3所示的流程来显示图像，显示屏则只能一直显示第2帧动效，如桌面402b和桌面402c。再后，当手机的负载降下来后，手机可以继续按照前述图3所示的流程来显示图像，但是此时已经需要渲染第5帧动效了，Launcher则会渲染第5帧动效，最终会显示桌面403对应的第5帧动效。很显然，显示屏连续显示了3帧第2帧动效，出现了卡顿，并且直接从第2帧动效过渡到第5帧动效，动效过渡的不流畅。
基于上述问题，本申请实施例提供了一种请求vSync信号的方法，该方法可应用于类似图1需要显示动态变化的连续多帧图像的场景，在这些场景中，相应的应用需要渲染连续多帧图像。参见图5，应用1在确定需要连续渲染多帧图像后，可以调用SF的setVsyncRate接口向SF请求vSync信号(如在图5中的t1时刻请求)。SF在接收到应用1通过setVsyncRate接口对vSync信号的请求后，周期性将vSync信号分发给应用1。从而可以周期性触发应用1渲染图像。如此，应用1可以实现渲染连续多帧图像。然后，应用1在确定结束渲染连续多帧图像后，可以调用SF的setVsyncRate接口向SF请求取消vSync信号(如在图5中的t2时刻请求)。SF在接收到应用1通过setVsyncRate接口取消对vSync信号的请求后，则结束周期性将vSync信号分发给应用1。为了方便说明，可以将t1时刻称为第一时刻，将t2时刻称为第二时刻，将调用setVsyncRate接口请求vSync信号的请求称为第一请求，将调用setVsyncRate接口 请求取消vSync信号的请求称为第二请求。
综上所述，采用本申请实施例，应用1仅需要向SF请求一次vSync信号，则可以接收到SF周期性分发的vSync信号，从而周期性触发应用1开始渲染。尤其在需要显示动态变化的连续多帧图像的场景中，SF周期性分发vSync信号，从而可以周期性触发应用1完成该连续多帧图像的渲染。无需应用1连续请求多次vSync信号，极大地减少了跨进程调用的次数，降低了对Binder线程的依赖。如此，可以降低动态变化的过程出现显示卡顿、不流畅的现象的可能。并且，应用1可以请求取消vSync信号，使SF结束向应用1周期性分发vSync信号，避免长期周期性分发造成资源浪费。
仍以图1所示显示桌面动效的场景为例，Launcher在检测到用户对桌面101中视频应用的应用图标102的点击操作后，Launcher可以确定需要渲染桌面103-桌面107所示的多帧动效，即需要渲染连续多帧图像。该情况下，Launcher可以调用SF的setVsyncRate接口向SF请求vSync信号，触发SF周期性的将vSync信号分发给Launcher。周期性的vSync信号可以触发Launcher依次渲染桌面103-桌面107所示的多帧动效。在完成多帧动效的渲染后，Launcher可以确定结束渲染连续多帧图像。该情况下，Launcher可以调用SF的setVsyncRate接口向SF请求取消vSync信号，触发SF结束周期性的将vSync信号分发给Launcher，减少资源浪费。
示例性的，本申请实施例中的电子设备可以是手机、平板电脑、桌面型、膝上型、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)\虚拟现实(virtual reality，VR)设备等支持显示功能的设备。本申请实施例对该电子设备的具体形态不作特殊限制。下文中，将主要以电子设备是手机为例，来说明本申请方案。
参见图6，为本申请实施例提供的一种电子设备的硬件结构图。如图6所示，以电子设备是手机600为例，电子设备可以包括处理器610，外部存储器接口620，内部存储器621，通用串行总线(universal serial bus，USB)接口630，充电管理模块640，电源管理模块641，电池642，天线1，天线2，移动通信模块650，无线通信模块660，音频模块670，扬声器670A，受话器670B，麦克风670C，耳机接口670D，传感器模块680，按键690，马达691，指示器692，摄像头693，显示屏694，以及用户标识模块(subscriber identification module，SIM)卡接口695等。
可以理解的是，本实施例示意的结构并不构成对手机600的具体限定。在另一些实施例中，手机600可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器610可以包括一个或多个处理单元，例如：处理器610可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
充电管理模块640用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块640可以通过USB接口630接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块640可以通过手机600的无线充电线圈接收无线充电输入。充电管理模块640为电池642充电的同时，还可以通过电源管理模块641为手机600供电。
电源管理模块641用于连接电池642，充电管理模块640与处理器610。电源管理模块641接收电池642和/或充电管理模块640的输入，为处理器610，内部存储器621，外部存储器，显示屏694，摄像头693，和无线通信模块660等供电。电源管理模块641还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块641也可以设置于处理器610中。在另一些实施例中，电源管理模块641和充电管理模块640也可以设置于同一个器件中。
手机600的无线通信功能可以通过天线1，天线2，移动通信模块650，无线通信模块660，调制解调处理器以及基带处理器等实现。
显示屏694用于显示图像，视频等。在一些实施例中，显示屏694可用于显示动态变化的界面内容，如图1所示的桌面动效。显示屏694包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot light emitting diodes，QLED)等。
手机600通过GPU，显示屏694，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏694和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器610可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
手机600可以通过ISP，摄像头693，视频编解码器，GPU，显示屏694以及应用处理器等实现拍摄功能。ISP用于处理摄像头693反馈的数据。摄像头693用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。在一些实施例中，手机600可以包括1个或N个摄像头693，N为大于1的正整数。
外部存储器接口620可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机600的存储能力。外部存储卡通过外部存储器接口620与处理器610通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器621可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器610通过运行存储在内部存储器621的指令，从而执行手机600的各种功能应用以及数据处理。
手机600可以通过音频模块670，扬声器670A，受话器670B，麦克风670C，耳机接口670D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
按键690包括电源键(也可称开机键)，音量键等。按键690可以是机械按键。也可以是触摸式按键。手机600可以接收按键输入，产生与手机600的用户设置以及功能控制有关的键信号输入。马达691可以产生振动提示。马达691可以用于来电振 动提示，也可以用于触摸振动反馈。指示器692可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口695用于连接SIM卡。
本申请实施例中，手机600的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构或云架构。下文实施例，将主要以分层架构的Android系统为例，示例性说明手机600的软件架构。
分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，参见图7，可以将Android系统分为六层，从上至下分别为应用程序层(applications)、框架层(framework)、Java本地接口层(Java Native Interface，JNI)、本地层(Native)、硬件抽象层(HAL)以及内核层(kernel)。
其中，应用程序层中可以安装通话、备忘录、桌面、浏览器、联系人、相机、图库、日历等应用。图7中仅示出了桌面应用(Launcher)。这些应用基本都需要通过手机600的显示屏来显示其应用界面。例如，Launcher需要通过显示屏来显示图1所示桌面101，桌面103-桌面107上的应用图标，以及显示图1所示桌面103-桌面107对应的动效。
框架层为应用程序层提供应用编程接口(application programming interface，API)和编程框架。框架层中包括显示屏渲染模块(Choreographer)以及标记模块(AnimationSmooth)。AnimationSmooth可用于应用保存渲染连续多帧图像的开关状态，开关状态包括开启状态和关闭状态。开启状态指示需要渲染连续多帧图像，关闭状态指示结束渲染连续多帧图像。
Choreographer可用于应用向SF请求vSync信号。也就是说，应用1需要通过Choreographer实现向SF请求vSync信号。那么，本文中应用1调用requestNextVsync接口或者setVsyncRate接口向SF请求vSync信号，实质是Choreographer调用requestNextVsync接口或者setVsyncRate接口向SF请求vSync信号；以及，应用1调用setVsyncRate接口向SF请求取消vSync信号，实质是Choreographer调用setVsyncRate接口向SF请求取消vSync信号。
并且，Choreographer可用于应用实现渲染。也就是说，应用1需要通过Choreographer实现渲染。那么，本文中SF向应用1分发vSync信号，触发应用1渲染，实质是SF向Choreographer分发vSync信号，触发Choreographer渲染。
本地层为上层(如框架层)提供各种服务。本地层中包括SF，SF可用于合成和送显，以及刷新率控制。其中，刷新率控制即：通过向应用分发vSync信号，控制应用在显示屏刷新一次后开始渲染。本地层中包括SF的requestNextVsync接口和setVsyncRate接口，这两个接口都可以实现请求vSync信号。其中，requestNextVsync接口可以实现每请求一次vSync信号，SF则分发一次vSync信号。setVsyncRate接口可以实现每请求一次vSync信号，SF则周期性分发vSync信号。
需要在此说明的是，框架层通常是采用Java语言编写的，因此，框架层也可以称为Java层。本地层是采用C++/C语言编写的，因此，本地层也可以称为C++/C层。Java本地接口层则是连接框架层和本地层之间的桥梁，用于打通框架层和本地层，使框架层和本地层之间可以相互访问。
Java本地接口层中包括对Java开放的接口，以便框架层通过该接口调用本地层提供的服务。本申请实施例中，需要调用SF的setVsyncRate接口向SF请求vSync信号，而SF中的setVsyncRate接口只是本地层中的接口，其并没有对Java开放接口。基于此，在一些实施例中，需要在框架层和Java本地接口层中分别新增一个接口，如图7中的第一接口和第二接口。通过第一接口、第二接口和setVsyncRate接口，打通框架层中的Choreographer到本地层中的SF之间的通路，使得应用可以调用setVsyncRate接口，实现向SF请求vSync信号。
硬件抽象层对底层硬件驱动进行了一层封装，并向上层提供调用驱动的通用接口，以供上层调用驱动从而驱动相应的硬件工作。硬件抽象层中包括硬件混合渲染器(Hwcomposer，HWC)。HWC可以和SF结合，完成合成处理。其中，SF可以使用OpenGL ES合成图层，但是该合成需要占用并消耗GPU资源。而HWC通过硬件设备进行图层合成，可以减轻GPU的合成压力。
内核层中包括驱动硬件工作的驱动，如显示驱动(Display drivers)。显示驱动用于驱动显示屏工作，并且将来上层的(如硬件抽象层)的图像数据流(如RGB图像数据流)传输给显示屏显示(即送显)。
本申请实施例提供的请求vSync信号的方法，可以在具有上述硬件结构和软件结构的手机600中实现。下面先结合上述手机600的软件架构，对本申请实施例提供的请求vSync信号的方法做简单介绍：
应用1在确定需要渲染连续多帧图像后，可以通过Choreographer，依次调用框架层中的第一接口、Java本地接口层中的第二接口以及本地层中的setVsyncRate接口，向SF请求vSync信号。SF在接收到Choreographer调用setVsyncRate接口对vSync信号的请求后，周期性将vSync信号分发给Choreographer，从而可以周期性触发Choreographer渲染应用1的图像。
然后，应用1在确定结束渲染连续多帧图像后，可以通过Choreographer，依次调用第一接口、第二接口以及setVsyncRate接口，向SF请求取消vSync信号。SF在接收到Choreographer调用setVsyncRate接口取消对vSync信号的请求后，则结束周期性将vSync信号分发给Choreographer。从而不会继续周期性触发Choreographer渲染应用1的图像。
其中，应用1可基于自身的显示逻辑确定是否需要渲染连续多帧图像。
示例一，以前文图1所示的场景为例，Launcher检测到用户对桌面上某应用图标(如视频应用的应用图标102)的点击操作后，其显示逻辑为：显示从应用图标放大到应用界面的桌面动效。该桌面动效需要Launcher显示动态变化的连续多个动效帧，即多帧图像来实现。那么，Launcher检测到用户对桌面上某应用图标的点击操作后，则可以确定需要渲染连续多帧图像。
示例二，仍以Launcher为例，Launcher检测到用户在桌面上的滑动(如向左或向右滑动)操作后，随着用户的滑动操作，桌面也会随之滑动。并且，在用户的滑动操作结束后，Launcher的显示逻辑为：继续滑动桌面直至完全显示桌面的某一个屏(如返回滑动操作前显示的屏，或者切换到上一屏，或者切换到下一屏)。上述继续滑动桌面直至完全显示桌面的某一个屏的过程需要Launcher显示动态变化的连续多帧图像 来实现。那么，Launcher检测到用户在桌面上的滑动操作结束后，则可以确定需要渲染连续多帧图像。
示例三，以日历应用为例，日历应用在检测到用户对月份的视图中某天的点击操作后，其显示逻辑为：显示从月份的视图变化到某天的视图的过渡动效，最终显示某天的视图。该过渡动效需要日历应用显示动态变化的连续多帧图像来实现。那么，日历应用检测到用户对月份的视图中某天的点击操作后，则可以确定需要渲染连续多帧图像。
也就是说，若在用户的触摸操作结束后，应用1需要在短时间内显示动态变化的连续多帧图像，如应用1需要以小于20ms的间隔显示滑动、缩放等动效，则应用1可以确定需要渲染连续多帧图像。而在完成该多帧图像的渲染后，或者，在结束该多帧图像的显示前、检测的到退出在前台运行应用1后，或者，在结束该多帧图像的显示前、检测到显示屏息屏，则应用1可以确定结束渲染连续多帧图像。
通常情况下，应用1在每次需要渲染新一帧图像之前，都需要通过Choreographer来请求vSync信号，以请求SF分发vSync信号。并且，Choreographer在接收到SF分发的vSync信号后，才会渲染应用1的图像。而在本申请实施例中，应用1仅需在确定需要渲染连续多帧图像后，通过Choreographer来请求一次vSync信号；以及，在确定结束渲染连续多帧图像后，通过Choreographer来请求取消vSync信号。也就是说，尽管需要渲染连续多帧图像，也仅需通过Choreographer来请求一次vSync信号，而无需在每次渲染一帧图像之前，均通过Choreographer来请求vSync信号。
参见图8，在一些实施例中，在需要渲染连续多帧图像的情况下，仅通过Choreographer来请求一次vSync信号的具体实现包括：
S801、应用1确定需要渲染连续多帧图像。
S802、在需要渲染多帧图像中的第一帧图像(也可以称为第一图像)时，应用1向Choreographer请求vSync信号。
应用1在需要渲染任一帧图像时，首先向Choreographer请求vSync信号，以请求渲染该任一帧图像(如第一图像)。从而触发Choreographer进一步向SF请求vSync信号。示例性的，应用1可以调用Choreographer的scheduleVsyncLocked接口，触发Choreographer向SF请求vSync信号。
为了方便说明，可以将应用1向Choreographer发送的、用于请求vSync信号的消息称为第一消息。
S803、Choreographer调用setVsyncRate接口向SF请求vSync信号。
也就是说，Choreographer在应用1确定渲染多帧图像后，首次接收到应用1对vSync信号的请求时，会调用setVsyncRate接口向SF请求vSync信号。即，在请求渲染多帧图像中的第一帧图像时，调用setVsyncRate接口向SF请求vSync信号，则图5中的t1时刻可以是请求渲染多帧图像中的第一帧图像的时刻。
示例性的，Choreographer调用第一接口、第二接口以及setVsyncRate接口时携带的参数为第一参数，用于指示请求vSync信号。例如，第一参数为1，则调用setVsyncRate接口具体为setVsyncRate(1)，表示调用setVsyncRate接口请求vSync信号。
S804、SF更新请求状态为周期性请求，SF中请求状态的初始值为未请求。
在本实施例中，请求状态进一步包括周期性请求。请求状态为周期性请求，可以指示SF将vSync信号周期性的分发给Choreographer。
示例性的，请求状态及其状态转移过程如图9所示，请求状态包括未请求(如none)、已请求(如single)以及周期性请求(如period)。请求状态为未请求，则指示无需分发vSync信号给应用1。请求状态为已请求，指示需要分发一次vSync信号给应用1。请求状态为周期性请求，指示需要周期性分发vSync信号给应用1。请求状态的初始值为未请求，在请求状态为未请求的情况下，Choreographer调用requestNextVsync接口向SF请求vSync信号，则请求状态会更新为已请求(可参见前文图5中的相关说明)。在请求状态为已请求的情况下，SF分发一次vSync信号给应用1后，则请求状态会更新为未请求(可参见前文图5中的相关说明)。在请求状态为未请求的情况下，Choreographer调用setVsyncRate接口向SF请求vSync信号(如setVsyncRate(1))，则请求状态会更新为周期性请求，如S803-S804所述。
需要在此说明的是，本文中的请求状态都是针对应用1而言的，实际上，SF中维护有各个应用的请求状态。每个应用的请求状态可以指示相应的应用对vSync信号的需求情况。
本实施例中，在需要渲染多帧图像中的第一帧图像时，则调用setVsyncRate接口向SF请求vSync信号，从而可以在确定需要渲染连续多帧图像后，及时使SF将请求状态更新为周期性请求。后续，SF则可以周期性分发vSync信号，触发依次完成多帧图像的渲染。
S805、显示屏向SF发送vSync信号。
显示屏完成一次刷新，则会向SF发送一次vSync信号。
S806、在请求状态为周期性请求的情况下，SF向Choreographer分发vSync信号。
需要在此说明的是，继续参见图9，在请求状态为周期性请求的情况下，SF向Choreographer分发vSync信号后，并不会将请求状态更新为未请求，而是会保持周期性请求不变。如此，SF后续接收到vSync信号后，才会继续分发给Choreographer，从而实现周期性分发。
Choreographer在接收到vSync信号后，则可以渲染多帧图像中的第一帧图像，然后发送给SF进行合成，最后送显，此处不再赘述。
S807、在需要渲染多帧图像中的第二帧图像时，应用1向Choreographer请求vSync信号。
经过前述S802-S804，SF已经将请求状态更新为周期性请求了，后续，SF则可以周期性分发vSync信号，触发依次完成多帧图像的渲染。因此，在请求渲染多帧图像中除第一帧图像之外的图像(也可以称为第二图像)时，即使应用1会向Choreographer请求vSync信号，Choreographer也无需再重复向SF请求vSync信号，如调用setVsyncRate接口向SF请求vSync信号。如此，可以实现在需要渲染连续多帧图像的情况下，仅通过Choreographer来请求一次vSync信号。
为了方便说明，可以将请求渲染多帧图像中除第一帧图像之外的任一帧图像的时刻称为第三时刻。
S808、显示屏向SF发送vSync信号。
显示屏再完成一次刷新，则可以显示S806之后Choreographer渲染，然后发送给SF进行合成，最后送显的图像，并且向SF发送vSync信号。
S809、在请求状态为周期性请求的情况下，向Choreographer分发vSync信号。
Choreographer在接收到vSync信号后，则可以渲染多帧图像中的第二帧图像，然后发送给SF进行合成，最后送显，此处不再赘述。
之后，只要请求状态保持为周期性请求，显示屏向SF发送vSync信号后，SF还会继续向Choreographer分发vSync信号，Choreographer则可以继续渲染多帧图像中的第三帧图像、第四帧图像……。
S810、应用1确定结束渲染连续多帧图像。
S811、在需要渲染多帧图像后的第一帧图像时，应用1向Choreographer请求vSync信号。
多帧图像渲染完成后，当需要渲染新一帧图像(即多帧图像后的第一帧图像，也可以称为第三图像)时，应用1同样会向Choreographer请求vSync信号，以请求渲染该新一帧图像。
S812、Choreographer调用setVsyncRate接口向SF请求取消vSync信号。
本实施例中，在完成多帧图像的渲染后，Choreographer首次接收到应用1对vSync信号的请求时，首先会调用setVsyncRate接口，向SF请求取消vSync信号。即，在请求渲染多帧图像后的第一帧图像时，调用setVsyncRate接口向SF请求取消vSync信号，则图5中的t2时刻可以是请求渲染多帧图像后的第一帧图像的时刻。
示例性的，Choreographer调用第一接口、第二接口以及setVsyncRate接口时携带的参数均为第二参数，用于指示请求取消vSync信号。例如，第二参数为0，则调用setVsyncRate接口具体为setVsyncRate(0)，表示调用setVsyncRate接口请求取消vSync信号。
S813、SF更新请求状态为未请求。
继续参见图9，在请求状态为周期性请求的情况下，Choreographer调用setVsyncRate接口向SF请求取消vSync信号(如setVsyncRate(0))，则请求状态会更新为未请求。
在请求状态更新为未请求之后，后续SF接收到vSync信号后，则不会继续周期性分发vSync信号。
本实施例中，在多帧图像渲染完成后，需要渲染新一帧图像时，则调用setVsyncRate接口向SF请求取消vSync信号，从而可以在多帧图像渲染完成后，及时使SF将请求状态更新为未请求。后续，SF则不会周期性分发vSync信号，可以节省资源。
上述实施例中，主要以周期为1来说明。即：Choreographer在调用setVsyncRate接口向SF请求vSync信号时，携带指示周期为1的参数，如setVsyncRate(1)，括号中的1指示周期为1；然后，SF每次接收vSync信号后，都会向Choreographer分发vSync信号。当然，周期也可以为2,3,4……。Choreographer在调用setVsyncRate接口向SF请求vSync信号时，携带指示周期n的参数，如setVsyncRate(n)，括号中的n指示周期为n。周期为2时，SF每收到2次vSync信号后，SF则向Choreographer 分发一次vSync。周期为3时，SF每收到3次vSync信号后，SF则向Choreographer分发一次vSync……。
在手机600的使用过程中，存在大量无需渲染连续多帧图像的场景。以时钟应用中的计时功能为例，其通常以秒(s)为单位更新倒计时，例如，倒计时15分钟，当前显示的是15:00，则下一次是过1s后显示14:59，而且1s完全足够用户执行退出在前台运行时钟应用的操作，或者足够用户执行息屏的操作。也就是说，时钟应用难以预估接下来是否需要继续显示倒计时的图像，如接着显示14:59，14:58，14:57……对应的图像。很显然，时钟应用的计时功能不属于需要渲染连续多帧图像的场景。在这些场景中，应用通常仅需在满足一定的条件时，渲染一帧图像即可。示例性的，以上述时钟应用的计时功能为例，时钟应用仅需每隔1s钟渲染一帧新的倒计时图像即可。又示例性的，以计算器应用为例，计算器应用在检测到用户对计算器的键盘中数字或者符号的一次点击操作，才需渲染一帧新的图像。
也就是说，在这些场景中，若采用前述周期性分发的方式，应用在每次渲染新一帧图像之前，需要调用setVsyncRate接口向SF请求vSync信号，以触发SF将来自显示屏的vSync信号分发给应用；并且，在该新一帧图像渲染完成后，应用则需要调用setVsyncRate接口向SF请求取消vSync信号，以触发SF结束将来自显示屏的vSync信号分发给应用。即，一帧图像的渲染，需要调用两次setVsyncRate接口。这显然会导致资源浪费。
基于此，在一些实施例中，在需要渲染连续多帧图像的场景中，调用setVsyncRate接口向SF请求vSync信号，在不需要渲染连续多帧图像的场景中，调用requestNextVsync接口向SF请求vSync信号。
在本实施例中，应用1可以记录是否需要渲染连续多帧图像的开关状态(也可以称为第一开关状态)。开关状态包括开启状态(如为true)和关闭状态(如为false)。其中，开关状态的初始值为关闭状态。开关状态为关闭状态，则指示不需要渲染连续多帧图像。开关状态为开启状态，则指示需要渲染连续多帧图像。应用1在需要渲染任一帧图像时，向Choreographer请求vSync信号后，Choreographer可先查询开关状态，并依据开关状态调用requestNextVsync接口或者setVsyncRate接口向SF请求vSync信号。
参见图10，以应用1将开关状态存储在前述图7所示框架层中的AnimationSmooth为例，本实施例的请求vSync信号的方法在图8的S801之前，进一步包括S1001-S1007：
S1001、在确定渲染连续多帧图像之前、需要渲染图像时，应用1向Choreographer请求vSync信号。
S1002、Choreographer从AnimationSmooth中查询开关状态，AnimationSmooth中开关状态的初始值为关闭状态。
S1003、Choreographer查询到的开关状态为关闭状态，调用requestNextVsync接口向SF请求vSync信号。
本实施例中，Choreographer在请求vSync信号之前，先查询AnimationSmooth中的开关状态。查询到为关闭状态，则表示当前没有渲染连续多帧图像的需求，因此，Choreographer可以调用requestNextVsync接口来请求vSync信号。从而实现请求一次 vSync信号，分发一次vSync信号。
S1004、SF更新请求状态为已请求，SF中应用1的请求状态的初始值为未请求。
S1005、显示屏向SF发送vSync信号。
S1006、在请求状态为已请求的情况下，SF向Choreographer分发vSync信号。
Choreographer在接收到vSync信号之后，则可以开始渲染，然后发送给SF进行合成，最终送显。
S1007、SF更新请求状态为未请求。
经过上述S1001-S1007，可以在需要渲染连续多帧图像之前，针对一帧图像，仅需调用requestNextVsync接口向SF请求一次vSync信号，SF则可分发一次vSync信号以触发Choreographer完成渲染，而无需请求一次vSync信号和请求取消vSync信号，从而可以减少跨进程通信，节省资源。
需要说明的是，前述S1001-S1007仅说明了在确定渲染连续多帧图像之前，渲染一帧图像的处理过程，实际中，在确定需要渲染连续多帧图像之前，可能有至少两帧图像需要渲染，每帧图像都可以采用上述S1001-S1007的过程来处理。
继续参见图10，在应用1确定需要渲染连续多帧图像之后，与前述图8所示的实施例不同的是：在S801之后，还包括S1008-S1009；在应用1向Choreographer请求vSync信号之后，还包括查询AnimationSmooth中的开关状态的步骤，如S1010、S1011；以及S803具体为S803a：
S801、应用1确定需要渲染连续多帧图像。
S1008、应用1触发AnimationSmooth更新开关状态。
S1009、AnimationSmooth更新开关状态为开启状态。
在本实施例中，应用1在确定需要渲染连续多帧图像时，首先需要将AnimationSmooth中的开关状态更新为开启状态，以指示需要渲染连续多帧图像。
S802、在需要渲染多帧图像中的第一帧图像时，应用1向Choreographer请求vSync信号。
S1010、Choreographer从AnimationSmooth中查询开关状态。
S803a、Choreographer查询到开关状态为开启状态，调用setVsyncRate接口请求vSync信号。
本实施例中，Choreographer在请求vSync信号之前，先查询AnimationSmooth中的开关状态。查询到为开启状态，则表示当前有渲染连续多帧图像的需求，因此，Choreographer可以调用setVsyncRate接口来请求vSync信号。
S804、SF更新请求状态为周期性请求。
S805、显示屏向SF发送vSync信号。
S806、在请求状态为周期性请求的情况下，SF向Choreographer分发vSync信号。
S807、在需要渲染多帧图像中的第二帧图像时，应用1向Choreographer请求vSync信号。
S1011、Choreographer从AnimationSmooth中查询开关状态。
同样的，Choreographer在请求vSync信号之前，先查询AnimationSmooth中的开关状态。查询到为开启状态，则表示当前有渲染连续多帧图像的需求。但是，经过前 述S802、S1010、S803a以及S804，SF已经将请求状态更新为周期性请求了，后续，SF则可以周期性分发vSync信号，触发依次完成多帧图像的渲染。因此，在需要渲染多帧图像中的第二帧图像以及之后的图像时，即使应用1请求vSync信号，Choreographer也查询到开关状态为开启状态，Choreographer无需再重复向SF请求vSync信号，如调用setVsyncRate接口向SF请求vSync信号。
S808、显示屏向SF发送vSync信号。
S809、在请求状态为周期性请求的情况下，向Choreographer分发vSync信号。
继续参见图10，在应用1确定结束渲染连续多帧图像之后，与前述图8所示的实施例不同的是：在S810之后，还包括S1012-S1013；在应用1向Choreographer请求vSync信号之后，还包括查询AnimationSmooth中的开关状态的步骤，如S1014；以及S812具体为S812a：
S810、应用1确定结束渲染连续多帧图像。
S1012、应用1触发AnimationSmooth更新开关状态。
S1013、AnimationSmooth更新开关状态为关闭状态。
在本实施例中，应用1在确定结束渲染连续多帧图像时，首先需要将AnimationSmooth中的开关状态更新为关闭状态，以指示结束渲染连续多帧图像。
S811、在需要渲染多帧图像后的第一帧图像时，应用1向Choreographer请求vSync信号。
S1014、Choreographer从AnimationSmooth中查询开关状态。
S812a、Choreographer查询到开关状态为关闭状态，并且前一次查询到为开启状态，调用setVsyncRate接口请求取消vSync信号。
Choreographer查询到开关状态为关闭状态，则表示当前无需连续渲染多帧需求；在此基础上，若前一次查询到的为开启状态，则表示刚结束渲染连续多帧图像的需求。此时，Choreographer则调用setVsyncRate接口请求取消vSync信号。
S813、SF更新请求状态为未请求。
进一步的，在一些实施例中，可以在AnimationSmooth和Choreographer中分别维护开关状态，从而可以在需要渲染连续多帧图像的场景中，调用setVsyncRate接口向SF请求vSync信号，在不需要渲染连续多帧图像的场景中，调用requestNextVsync接口向SF请求vSync信号；还可以准确确定调用setVsyncRate接口向SF请求vSync信号和取消vSync信号的时机。其中，AnimationSmooth和Choreographer中的开关状态的初始值均为关闭状态。为了区分第一开关状态，可以将Choreographer中的开关状态称为第二开关状态。
在本实施例中，Choreographer在请求vSync信号之前，需要先查询AnimationSmooth中的开关状态，并基于查询到的开关状态和Choreographer本地的开关状态，确定是否向SF请求vSync信号，以及确定调用setVsyncRate接口或者requestNextVsync接口向SF请求vSync信号。
参见图11，本实施例包括如下步骤：
S1001、在确定需要渲染连续多帧图像之前、需要渲染图像时，应用1向Choreographer请求vSync信号。
为了方便说明，可以将请求渲染多帧图像之前、需要渲染的任一帧图像的时刻称为第四时刻。
S1002、Choreographer从AnimationSmooth中查询开关状态，AnimationSmooth中开关状态的初始值为关闭状态。
继续参见图11，前述图10中的S1003具体可以为如下S1003a：
S1003a、Choreographer查询到的开关状态与Choreographer本地的开关状态均为关闭状态，调用requestNextVsync接口向SF请求vSync信号。
为了方便说明，可以将调用requestNextVsync接口请求vSync信号、以渲染多帧图像前的任一帧图像的请求称为第四请求。
本实施例中，Choreographer在请求vSync信号之前，先查询AnimationSmooth中的开关状态。查询到为关闭状态，则表示当前没有渲染连续多帧图像的需求，因此，Choreographer需要调用requestNextVsync接口来请求vSync信号，从而实现请求一次vSync信号，分发一次vSync信号。并且，Choreographer本地的开关状态为关闭状态，表示此时并不是刚结束渲染连续多帧图像的需求。因此，Choreographer无需调用requestNextVsync接口来请求取消vSync信号。那么，在查询到的开关状态和本地的开关状态均为关闭状态时，则可以调用requestNextVsync接口来请求vSync信号。
S1004、SF更新请求状态为已请求，SF中应用1的请求状态的初始值为未请求。
S1005、显示屏向SF发送vSync信号。
S1006、在请求状态为已请求的情况下，SF向Choreographer分发vSync信号。
S1007、SF更新请求状态为未请求。
S801、应用1确定需要渲染连续多帧图像。
S1008、应用1触发AnimationSmooth更新开关状态。
S1009、AnimationSmooth更新开关状态为开启状态。
S802、在需要渲染多帧图像中的第一帧图像时，应用1向Choreographer请求vSync信号。
S1010、Choreographer从AnimationSmooth中查询开关状态。
继续参见图11，前述图10中的S803a进一步包括如下S1101-S1102：
S1101、Choreographer查询到的开关状态为开启状态，Choreographer本地的开关状态为关闭状态，更新Choreographer本地的开关状态为开启状态。
更新Choreographer本地的开关状态为开启状态，从而使Choreographer本地的开关状态与应用1是否需要渲染连续多帧图像的需求保持一致。例如，应用1需要渲染连续多帧图像，则Choreographer本地的开关状态更新为开启状态。
S1102、Choreographer调用setVsyncRate接口向SF请求vSync信号。
本实施例中，Choreographer在请求vSync信号之前，先查询AnimationSmooth中的开关状态。查询到为开启状态，并且更新前Choreographer本地的开关状态为关闭状态，表明应用1刚从不需要渲染连续多帧图像转变为需要渲染连续多帧图像，因此，Choreographer需要调用setVsyncRate接口来请求vSync信号，及时触发SF周期性分发vSync信号。从而实现请求一次vSync信号，SF周期性分发vSync信号。
S804、SF更新请求状态为周期性请求。
S805、显示屏向SF发送vSync信号。
S806、在请求状态为周期性请求的情况下，SF向Choreographer分发vSync信号。
S807、在需要渲染多帧图像中的第二帧图像时，应用1向Choreographer请求vSync信号。
S1011、Choreographer从AnimationSmooth中查询开关状态。
继续参见图11，在前述图10中的S1011之后，还包括如下S1103：
S1103、Choreographer查询的开关状态与本地的开关状态均为开启状态，则不继续请求vSync信号。
Choreographer查询的开关状态为开启状态，表示当前有渲染连续多帧图像的需求，因此，Choreographer需要调用setVsyncRate接口来请求vSync信号。但是，查询到的开关状态与更新前Choreographer本地的开关状态一致，表明应用1并不是刚从不需要渲染连续多帧图像转变为需要渲染连续多帧图像，此前Choreographer应该已经调用setVsyncRate接口来请求过vSync信号(如S1102)，因此，Choreographer不需要重复调用setVsyncRate接口来请求vSync信号。那么，在查询到的开关状态和本地的开关状态均为开启状态时，则无需重复调用requestNextVsync接口来请求vSync信号。从而可以避免重复调用requestNextVsync接口来请求vSync信号，保证在需要渲染连续多帧图像的场景中，仅通过调用requestNextVsync接口来请求一次vSync信号。
S808、显示屏向SF发送vSync信号。
S809、在请求状态为周期性请求的情况下，向Choreographer分发vSync信号。
S810、应用1确定结束渲染连续多帧图像。
S1012、应用1触发AnimationSmooth更新开关状态。
S1013、AnimationSmooth更新开关状态为关闭状态。
S811、在需要渲染多帧图像后的第一帧图像时，应用1向Choreographer请求vSync信号。
S1014、Choreographer从AnimationSmooth中查询开关状态。
继续参见图11，前述图10中的S812a进一步包括如下S1104-S1105：
S1104、Choreographer查询到的开关状态为关闭状态，本地的开关状态为开启状态，更新本地的开启状态为关闭状态。
更新Choreographer本地的开关状态为关闭状态，从而使Choreographer本地的开关状态与应用1是否需要渲染连续多帧图像的需求保持一致。例如，应用1不需要渲染连续多帧图像，则Choreographer本地的开关状态更新为关闭状态。
S1105、Choreographer调用setVsyncRate接口向SF请求取消vSync信号。
Choreographer查询的开关状态为关闭状态，并且，更新前Choreographer本地的开关状态为开启状态，表明应用1刚从需要渲染连续多帧图像转变为不需要渲染连续多帧图像，因此，Choreographer需要先调用setVsyncRate接口来请求取消vSync信号，避免在结束渲染连续多帧图像的需求后，SF仍然周期性的分发vSync信号。从而可以在结束渲染连续多帧图像的需求后，及时触发SF结束周期性发送vSync信号。
S813、SF更新请求状态为未请求。
截止前述S813，将请求状态由周期性请求更新为未请求，那么，SF则不会继续 周期性分发vSync信号。但是，应用1当前需要渲染多帧图像之后的第一帧图像，因此，继续参见图11，在S813之后，还需要执行下述S1106-S1110，以完成多帧图像后的新一帧图像的渲染：
S1106、Choreographer调用requestNextVsync接口向SF请求vSync信号。
由于当前已经结束渲染连续多帧图像，因此，Choreographer需要调用requestNextVsync接口向SF请求vSync信号，以实现请求一次vSync信号，SF则分发一次vSync信号。
也就是说，本实施例中，Choreographer在调用setVsyncRate接口向SF请求取消vSync信号后，还需要调用requestNextVsync接口向SF请求vSync信号。为了方便说明，可以将调用requestNextVsync接口请求vSync信号、以渲染多帧图像后的第一帧图像的请求称为第三请求。
S1107、SF更新请求状态为已请求。
S1108、显示屏向SF发送vSync信号。
S1109、在请求状态为已请求的情况下，SF向Choreographer分发vSync信号。
SF向Choreographer分发vSync信号，则可以触发Choreographer完成多帧图像后的新一帧图像的渲染，然后发送给SF进行合成，最终送显。
S1110、SF更新请求状态为未请求。
至此，需要说明的是，前述图11的实施例中仅说明到多帧图像之后的一帧图像的处理过程，此后，若还有需要渲染的图像，则可以重复按照前述图11所示的流程来处理。本实施例这种不再一一赘述。
另外，前述图11的实施例中，针对AnimationSmooth中的开关状态和Choreographer中的开关状态的四种不同组合，Choreographer需要分别采用对应的方式来处理，包括前述S1003a所示的第一种方式，S1101-S1102所示的第二种方式，S1103所示的第三种方式，以及S1104-S1105、S1106所示的第四种方式。从而可以保证准确的调用requestNextVsync接口或者setVsyncRate接口请求vSync信号，或者调用setVsyncRate接口请求取消vSync信号。
在另一些实施例中，与前述图11中S1104-S1105、S1106所示的第四种方式不同的是：Choreographer在查询到的开关状态为关闭状态(即AnimationSmooth中开关状态为关闭状态)，本地的开关状态为开启状态(即Choreographer中的开关状态为开启状态)的情况下，首先更新本地的开启状态为关闭状态，然后直接调用requestNextVsync接口向SF请求vSync信号。在本实施例中，请求状态可以在周期性请求和已请求之间转移，如图9中的虚线箭头所示，在请求状态为周期性请求的情况下，Choreographer调用requestNextVsync接口向SF请求vSync信号，则请求状态会更新为已请求。那么，后续则可以继续执行S1107-S1110，完成对多帧图像之后的新一帧图像的渲染。也就是说，与图11所示的实施例不同的是：本实施例中可以省略S1105和S813，而可以通过直接调用requestNextVsync接口向SF请求vSync信号，使请求状态由周期性请求转变为已请求，从而可以在结束周期性分发的同时，实现请求一次vSync信号，分发一次vSync信号。
前述实施例中，都是在应用1确定结束渲染连续多帧图像后，SF则结束周期性分 发vSync信号。而在另一些实施例中，也可以由Choreographer确定是否结束渲染连续多帧图像。本实施例中，应用1在每次需要渲染任一帧图像(也可以称为第四图像)时，可以向Choreographer请求vSync信号，此时Choreographer可以记录处理状态为未处理状态(也可以称为第一标记)。未处理状态指示有需要渲染的图像。然后，当Choreographer接收到来自SF的vSync信号后，则可以更新处理状态为已处理状态。已处理状态指示没有需要渲染的图像。
在本实施例中，Choreographer在每次接收到来自SF的vSync信号后，可以判断处理状态是否为未处理状态。若处理状态为未处理状态，表明应用1有需要渲染的图像，则可以触发Choreographer渲染该图像，并更新处理状态为已处理状态。若处理状态不是未处理状态，则表明应用1并没有需要渲染的图像。也就是说，当前接收到的vSync信号是多余的。应理解，若通过调用requestNextVsync接口向SF请求vSync信号，SF是请求一次，分发一次vSync信号，不会分发多余的vSync信号。那么，该多余的vSync信号极有可能是通过调用setVsyncRate接口向SFSF请求vSync信号后，SF周期性分发的。针对这种情况，Choreographer可以确定当前已经结束渲染连续多帧图像的需求，Choreographer可以调用setVsyncRate接口向SF请求取消vSync信号。后续，SF则可以结束周期性分发vSync信号。如此，Choreographer可以在发现多余的vSync信号后，及时触发SF结束周期性分发vSync信号。
参见图12，本实施例中，Choreographer发现多余的vSync信号后，上述图11所示的实施例中的S810及其之后的步骤可以替换为图12中S1201-S1213的处理过程：
S1201、Choreographer接收到vSync信号，但处理状态不是未处理状态，确定结束渲染连续多帧图像。
S1202、Choreographer调用setVsyncRate接口向SF请求取消vSync信号。
即，在Choreographer不包括未处理状态、但接收到来自SF的vSync信号时，调用setVsyncRate接口向SF请求取消vSync信号。为了方便说明，可以将Choreographer不包括未处理状态、但接收到来自SF的vSync信号的时刻也称为第二时刻。
S1203、SF更新请求状态为未请求。
S1204、Choreographer触发AnimationSmooth更新开关状态。
S1205、AnimationSmooth更新开关状态为关闭状态。
S1206、Choreographer更新开关状态为关闭状态。
也就是说，Choreographer在确定结束渲染连续多帧图像后：第一方面如S1202所示，Choreographer需要向SF请求取消vSync信号，使SF结束周期性分发vSync信号。第二方面如S1204所示，Choreographer需要触发AnimationSmooth更新开关状态为关闭状态，使AnimationSmooth中的开关状态指示应用1结束渲染连续多帧图像。第三方面如S1206所示，Choreographer更新本地的开关状态为关闭状态，使本地的开关状态指示应用1结束渲染连续多帧图像。需要说明的是，上述三个方面的执行顺序并不以图12所示为限，实际实施时，上述三个方面的先后顺序没有严格限制。
S1207、应用1在需要渲染多帧图像后的第一帧图像时，向Choreographer请求vSync信号。
S1208、Choreographer查询开关状态。
S1209、Choreographer查询到的开关状态和本地的开关状态均为关闭状态，调用requestNextVsync接口向SF请求vSync信号。
也就是说，本实施例中，针对多帧图像之后的第一帧图像，Choreographer可以直接调用requestNextVsync接口向SF请求vSync信号，而无需先调用setVsyncRate接口向SF请求取消vSync信号。
S1210、SF更新请求状态为已请求。
S1211、显示屏向SF发送vSync信号。
S1212、在请求状态为已请求的情况下，SF向分发ChoreographervSync信号。
S1213、SF更新请求状态为未请求。
本申请实施例还提供一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，电子设备可执行上述方法实施例中手机执行的各个功能或者步骤。
本申请实施例还提供一种芯片系统，如图13所示，该芯片系统1300包括至少一个处理器1301和至少一个接口电路1302。处理器1301和接口电路1302可通过线路互联。例如，接口电路1302可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路1302可用于向其它装置(例如处理器1301)发送信号。示例性的，接口电路1302可读取存储器中存储的指令，并将该指令发送给处理器1301。当所述指令被处理器1301执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。
本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的图像处理方法。
本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的图像处理方法。
另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的图像处理方法。
其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多 个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是，以上实施例仅用以说明本申请的技术方案而非限制，尽管参照较佳实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，可以对本申请的技术方案进行修改或等同替换，而不脱离本申请技术方案的精神和范围。

Claims (18)

  1. 一种请求vSync信号的方法，其特征在于，用于具有显示功能的电子设备，所述电子设备中安装有第一应用，所述方法包括：
    在第一时刻，所述电子设备中的第一应用调用所述电子设备中窗口系统SF的setVsyncRate接口，向所述SF发送第一请求，所述第一请求用于请求vSync信号；
    响应于所述第一请求，所述SF周期性向所述第一应用分发所述vSync信号；
    在第二时刻，所述第一应用调用所述setVsyncRate接口，向所述SF发送第二请求，所述第二请求用于请求取消vSync信号，所述SF在接收到所述第二请求之后，结束周期性向所述第一应用分发所述vSync信号。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    所述第一应用确定需要渲染连续多帧图像，所述第一时刻包括请求渲染第一图像的时刻，所述第一图像为所述多帧图像中的第一帧图像。
  3. 根据权利要求2所述的方法，其特征在于，所述第一应用记录第一开关状态，所述电子设备的框架层的渲染模块中记录第二开关状态，所述第一开关状态和所述第二开关状态的初始值均为关闭状态；
    在所述第一应用确定需要渲染连续多帧图像之后，所述方法还包括：
    所述第一应用更新所述第一开关状态为开启状态；
    所述在第一时刻，所述电子设备中的第一应用调用所述电子设备中窗口系统SF的setVsyncRate接口，向所述SF发送第一请求，包括：
    在所述第一时刻，所述第一应用向所述渲染模块发送第一消息，所述第一消息用于请求vSync信号；
    响应于所述第一消息，且所述第一开关状态为所述开启状态，所述第二开关状态为所述关闭状态，所述渲染模块调用所述setVsyncRate接口，向所述SF发送第一请求。
  4. 根据权利要求3所述的方法，其特征在于，所述第一开关状态为所述开启状态，所述第二开关状态为所述关闭状态，所述方法还包括：
    所述渲染模块更新所述第二开关状态为所述开启状态。
  5. 根据权利要求4所述的方法，其特征在于，所述方法还包括：
    在第三时刻，所述第一应用向所述渲染模块发送第一消息，所述第一消息用于请求vSync信号，所述第三时刻为请求渲染第二图像的时刻，所述第二图像为所述多帧图像中除所述第一帧图像之外的任一图像；
    响应于所述第一消息，且所述第一开关状态为所述开启状态，所述第二开关状态为所述开启状态，所述渲染模块不向所述SF请求所述vSync信号。
  6. 根据权利要求4或5所述的方法，其特征在于，在所述向所述SF发送第一请求之后，所述方法还包括：
    所述第一应用确定结束渲染连续多帧图像，所述第二时刻包括请求渲染第三图像的时刻，所述第三图像为完成所述多帧图像的渲染后、所述第一应用需要渲染的第一帧图像。
  7. 根据权利要求6所述的方法，其特征在于，在所述第一应用确定结束渲染连续 多帧图像之后，所述方法还包括：
    所述第一应用更新所述第一开关状态为所述关闭状态；
    所述在第二时刻，所述第一应用调用所述setVsyncRate接口，向所述SF发送第二请求，包括：
    在所述第二时刻，所述第一应用向所述渲染模块发送第一消息，所述第一消息用于请求vSync信号；
    响应于所述第一消息，且所述第一开关状态为所述关闭状态，所述第二开关状态为所述开启状态，所述渲染模块调用所述setVsyncRate接口，向所述SF发送第二请求。
  8. 根据权利要求7所述的方法，其特征在于，所述第一开关状态为所述关闭状态，所述第二开关状态为所述开启状态，所述方法还包括：
    所述渲染模块更新所述第二开关状态为所述关闭状态。
  9. 根据权利要求7或8所述的方法，其特征在于，在所述向所述SF发送第二请求之后，所述方法还包括：
    所述第一应用调用所述SF的requestNextVsync接口，向所述SF发送第三请求，所述第三请求用于请求vSync信号；
    响应于所述第三请求，所述SF向所述第一应用分发一次所述vSync信号。
  10. 根据权利要求4或5所述的方法，其特征在于，所述SF周期性向所述第一应用分发所述vSync信号，包括：
    所述SF周期性向所述渲染模块分发所述vSync信号。
  11. 根据权利要求10所述的方法，其特征在于，所述方法还包括：
    在第一应用需要渲染第四图像时，向渲染模块发送所述第一消息，第四图像是第一应用需要显示的任一帧图像，所述第四图像包括所述第一图像或者所述第二图像；
    响应于第一消息，渲染模块记录第一标记，并在接收到来自所述SF的所述vSync信号后，删除所述第一标记；
    其中，第二时刻包括所述渲染模块在不包括所述第一标记的情况下，接收到来自所述SF的所述vSync信号的时刻。
  12. 根据权利要求11所述的方法，其特征在于，所述方法还包括：
    在所述第二时刻，所述渲染模块通知所述第一应用将所述第一开关状态更新为所述关闭状态，所述渲染模块更新所述第二开关状态为所述关闭状态。
  13. 根据权利要求3-12中任一项所述的方法，其特征在于，所述方法还包括：
    在第四时刻，所述第一应用向所述渲染模块发送第一消息，所述第一消息用于请求vSync信号；
    响应于所述第一消息，且所述第一开关状态和所述第二开关状态均为所述关闭状态，所述渲染模块调用所述requestNextVsync接口，向所述SF发送第四请求，所述第四请求用于请求vSync信号。
  14. 根据权利要求1-13中任一项所述的方法，其特征在于，所述SF位于所述电子设备的本地层，所述第一应用位于所述电子设备的应用程序层，在所述向所述SF发送第一请求之前，所述方法还包括：
    在所述电子设备的框架层中新增第一接口，在所述电子设备的Java本地接口层中新增第二接口，所述第一接口和所述第二接口是所述setVsyncRate接口对Java开放的接口；
    所述第一应用调用所述setVsyncRate接口，包括：
    所述第一应用依次经过所述第一接口和所述第二接口调用所述setVsyncRate接口。
  15. 根据权利要求1-14中任一项所述的方法，其特征在于，所述第一请求中包括周期n，n≥1，n为整数；
    所述响应于所述第一请求，所述SF周期性向所述第一应用分发所述vSync信号，包括：
    响应于所述第一请求，所述SF在每接收到n次所述vSync信号后，向所述第一应用分发一次所述vSync信号。
  16. 一种电子设备，其特征在于，所述电子设备包括存储器和处理器，所述存储器和所述处理器耦合；其中，所述存储器中存储有计算机程序代码，所述计算机程序代码包括计算机指令，当所述计算机指令被所述处理器执行时，使得所述电子设备执行如权利要求1-15中任一项所述的方法。
  17. 一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-15中任一项所述的方法。
  18. 一种芯片系统，其特征在于，所述芯片系统应用于包括处理器和存储器的电子设备，所述芯片系统包括一个或多个接口电路和一个或多个处理器，所述接口电路和所述处理器通过线路互联，所述接口电路用于从所述电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令，当所述处理器执行所述计算机指令时，使得所述电子设备执行如权利要求1-15中任一项所述的方法。
PCT/CN2023/117580 2022-09-14 2023-09-07 一种请求vSync信号的方法及电子设备 Ceased WO2024055904A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/993,937 US20260018147A1 (en) 2022-09-14 2023-09-07 Method for requesting vsync signal and electronic device
EP23864636.8A EP4538875A4 (en) 2022-09-14 2023-09-07 VSYNC SIGNAL REQUEST METHOD AND ELECTRONIC DEVICE
CN202380066090.1A CN119856158A (zh) 2022-09-14 2023-09-07 一种请求vSync信号的方法及电子设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211116851.3A CN117742835A (zh) 2022-09-14 2022-09-14 一种请求vSync信号的方法及电子设备
CN202211116851.3 2022-09-14

Publications (1)

Publication Number Publication Date
WO2024055904A1 true WO2024055904A1 (zh) 2024-03-21

Family

ID=90259670

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/117580 Ceased WO2024055904A1 (zh) 2022-09-14 2023-09-07 一种请求vSync信号的方法及电子设备

Country Status (4)

Country Link
US (1) US20260018147A1 (zh)
EP (1) EP4538875A4 (zh)
CN (2) CN117742835A (zh)
WO (1) WO2024055904A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025227883A1 (zh) * 2024-04-30 2025-11-06 华为技术有限公司 图形渲染的方法、装置和电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108228358A (zh) * 2017-12-06 2018-06-29 广东欧珀移动通信有限公司 修正垂直同步信号的方法、装置、移动终端以及存储介质
US20190206367A1 (en) * 2016-08-23 2019-07-04 Samsung Electronics Co., Ltd. Electronic device, and method for controlling operation of electronic device
CN114443269A (zh) * 2021-08-27 2022-05-06 荣耀终端有限公司 帧率调节方法和相关装置
CN114518817A (zh) * 2022-01-10 2022-05-20 荣耀终端有限公司 一种显示方法、电子设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190206367A1 (en) * 2016-08-23 2019-07-04 Samsung Electronics Co., Ltd. Electronic device, and method for controlling operation of electronic device
CN108228358A (zh) * 2017-12-06 2018-06-29 广东欧珀移动通信有限公司 修正垂直同步信号的方法、装置、移动终端以及存储介质
CN114443269A (zh) * 2021-08-27 2022-05-06 荣耀终端有限公司 帧率调节方法和相关装置
CN114518817A (zh) * 2022-01-10 2022-05-20 荣耀终端有限公司 一种显示方法、电子设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4538875A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025227883A1 (zh) * 2024-04-30 2025-11-06 华为技术有限公司 图形渲染的方法、装置和电子设备

Also Published As

Publication number Publication date
CN117742835A (zh) 2024-03-22
CN119856158A (zh) 2025-04-18
US20260018147A1 (en) 2026-01-15
EP4538875A4 (en) 2025-07-02
EP4538875A1 (en) 2025-04-16

Similar Documents

Publication Publication Date Title
CN114648951B (zh) 控制屏幕刷新率动态变化的方法及电子设备
CN116052618B (zh) 一种屏幕刷新率切换方法及电子设备
CN114518817B (zh) 一种显示方法、电子设备及存储介质
CN114661263A (zh) 一种显示方法、电子设备及存储介质
CN117234319B (zh) 一种屏幕刷新率的设置方法及电子设备
WO2021056364A1 (en) Methods and apparatus to facilitate frame per second rate switching via touch event signals
WO2024016798A9 (zh) 图像显示方法和相关装置
CN115640083A (zh) 一种可提升动效性能的屏幕刷新方法及设备
CN118626201B (zh) 运行帧率控制方法、电子设备、芯片系统及可读存储介质
WO2024055904A1 (zh) 一种请求vSync信号的方法及电子设备
CN121368783A (zh) 一种图层合成方法、电子设备及存储介质
EP4538852A1 (en) Image processing method and electronic device
CN121014208A (zh) 一种图像处理方法和电子设备
CN118409839B (zh) 应用程序启动方法与电子设备
CN119071562A (zh) 一种图像处理方法和电子设备
CN117724779B (zh) 一种生成界面图像的方法及电子设备
CN120153353A (zh) 一种窗口动画处理方法及电子设备
CN121750778A (zh) 一种图像处理方法及电子设备
CN120238754A (zh) 一种图像处理方法及电子设备
CN117971087A (zh) 数据处理方法和相关装置
CN120469659A (zh) 图像显示方法、电子设备、芯片系统、存储介质及程序产品
WO2026085869A1 (zh) 数据处理方法、电子设备、可读介质及程序产品
WO2025060779A1 (zh) 一种调频方法及电子设备
CN121889760A (zh) 数据处理方法、电子设备、可读介质及程序产品
CN120144081A (zh) 图形渲染的方法、装置和电子设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23864636

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023864636

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 18993937

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2023864636

Country of ref document: EP

Effective date: 20250110

WWE Wipo information: entry into national phase

Ref document number: 202380066090.1

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2023864636

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 202380066090.1

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 18993937

Country of ref document: US