A method and device for determining game frame rate, an electronic device, and a storage medium

Abstract

The present disclosure relates to a method and apparatus for determining a game frame rate, an electronic device, and a storage medium. The method includes: reading a frame rate parameter of a target game process currently running from a preset object, where the frame rate parameter of the target game process is determined based on a User-Mode Driver (UMD); determining a running frame rate of the target game process based on the frame rate parameter of the target game process. Embodiments of the present disclosure can effectively and quickly determine the running frame rate of the target game process without forcibly injecting a DLL file for obtaining the frame rate into the running target game process, and thus will not affect the running speed of the target game process.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technologies, and in particular, to a method and apparatus for determining a game frame rate, an electronic device, and a storage medium. Background Art

[0002] The game frame rate (Frames Per Second, FPS) refers to the number of frames transmitted per second of the game screen. Generally speaking, the higher the FPS, the smoother the game screen; conversely, the lower the FPS, the more laggy the game screen. Generally speaking, the minimum FPS requirement to ensure a smooth game screen is 30fps. However, due to the limitation of the screen refresh rate, if the FPS is increased beyond the screen refresh rate, the smoothness of the game will not be improved. On the contrary, it will waste the graphics rendering ability of the Graphics Processing Unit (GPU). Therefore, for a game, selecting an appropriate game frame rate can not only improve the screen smoothness without causing frame rate waste, but also serve as an important criterion for evaluating the game screen quality. The operation of a game is based on the graphics card, and the update of the graphics card driver will determine the game frame rate. For a fixed version of the game, the higher the FPS value, the better the optimization of the graphics card driver. Therefore, determining the game frame rate during the game operation is a technical problem that needs to be urgently solved. Summary of the Invention

[0003] The present disclosure provides a technical solution for a method and apparatus for determining a game frame rate, an electronic device, and a storage medium.

[0004] According to an aspect of the present disclosure, there is provided a method for determining a game frame rate, including: reading frame rate parameters of a target game process currently running from a preset object, where the frame rate parameters of the target game process are determined based on the UMD; and determining the running frame rate of the target game process based on the frame rate parameters of the target game process.

[0005] In a possible implementation, the frame rate parameters of the target game process include: frame rate parameters of each rendering thread of the target game process.

[0006] In a possible implementation, the reading frame rate parameters of the target game process currently running from a preset object includes: reading the frame rate parameters of the target game process from the preset object based on a preset inter-process communication method; when the preset inter-process communication method is shared memory, the preset object is the shared memory; when the preset inter-process communication method is one of the following: signal, pipe, Socket, message queue, the preset object is the UMD.

[0007] In a possible implementation, the preset object is a shared memory; the method further includes: after the target game process is started, creating, based on the UMD, the shared memory corresponding to the target game process, where the shared memory is used to store the frame rate parameters of each rendering thread of the target game process.

[0008] In a possible implementation, the preset object is a shared memory, and the shared memory includes a first shared memory and a second shared memory; the method further includes: after the target game process is started, creating, based on the UMD, the first shared memory corresponding to the target game process, where the first shared memory is used to store the TID and Device pointer information of each rendering thread of the target game process; based on the TID and Device pointer information corresponding to each rendering thread of the target game process, creating, based on the UMD, the second shared memory corresponding to each rendering thread of the target game process, where the second shared memory corresponding to each rendering thread is used to store the frame rate parameter of this rendering thread.

[0009] In a possible implementation, the reading of the frame rate parameters of the currently running target game process from the preset object includes: reading the TID and Device pointer information corresponding to each rendering thread of the target game process from the first shared memory; for any one rendering thread of the target game process, based on the TID and Device pointer information corresponding to this rendering thread, reading the frame rate parameter of this rendering thread from the second shared memory corresponding to this rendering thread.

[0010] In a possible implementation, the determining of the running frame rate of the target game process based on the frame rate parameters of the target game process includes: for any one rendering thread of the target game process, determining the rendering frame rate of this rendering thread based on the frame rate parameter of this rendering thread; determining the running frame rate of the target game process based on the rendering frame rates of each rendering thread of the target game process.

[0011] In a possible implementation, the frame rate parameter of each rendering thread of the target game process includes: the number of thread frames at different times in this rendering thread; the determining of the rendering frame rate of any one rendering thread of the target game process based on the frame rate parameter of this rendering thread includes: determining the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in this rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment; determining the rendering frame rate of this rendering thread based on the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in this rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment.

[0012] In a possible implementation, determining the running frame rate of the target game process based on the rendering frame rate of each rendering thread of the target game process includes: performing normalization processing on the rendering frame rate of each rendering thread of the target game process to obtain the running frame rate of the target game process.

[0013] According to one aspect of the present disclosure, there is provided a game frame rate determination device, including: a parameter reading module configured to read the frame rate parameter of a currently running target game process from a preset object, where the frame rate parameter of the target game process is determined based on UMD; a frame rate determination module configured to determine the running frame rate of the target game process based on the frame rate parameter of the target game process.

[0014] According to one aspect of the present disclosure, there is provided an electronic device, including: a processor; a memory for storing instructions executable by the processor; wherein, the processor is configured to call the instructions stored in the memory to execute the above method.

[0015] According to one aspect of the present disclosure, there is provided a computer-readable storage medium having computer program instructions stored thereon, and when the computer program instructions are executed by a processor, the above method is implemented.

[0016] In the embodiments of the present disclosure, for any game that uses a User Mode Driver (UMD) to implement the graphics card driver, since the drawing and rendering during the game operation need to call the UMD interface, therefore, the frame rate parameter of the currently running target game process determined based on UMD can be directly read from a preset object, and then the running frame rate of the target game process can be effectively and quickly determined based on the frame rate parameter of the target game process, without forcibly injecting a DLL file for obtaining the frame rate into the running target game process, and thus the running speed of the target game process will not be affected.

[0017] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit the present disclosure. Other features and aspects of the present disclosure will become clear according to the following detailed description of exemplary embodiments with reference to the accompanying drawings. Description of the Drawings

[0018] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification. These drawings illustrate embodiments consistent with the present disclosure and are used together with the specification to explain the technical solutions of the present disclosure.

[0019] Figure 1 A flowchart showing a game frame rate determination method according to an embodiment of the present disclosure.

[0020] Figure 2Schematic diagram showing a method for determining game frame rate according to an embodiment of the present disclosure.

[0021] Figure 3 Block diagram showing a device for determining game frame rate according to an embodiment of the present disclosure.

[0022] Figure 4 Block diagram showing an electronic device according to an embodiment of the present disclosure. Detailed implementation manners

[0023] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0024] The special term "exemplary" herein means "serving as an example, embodiment or illustration". Any embodiment described as "exemplary" herein is not necessarily to be construed as superior or better than other embodiments.

[0025] The term "and / or" herein is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the term "at least one" herein means any one of a plurality or any combination of at least two of a plurality. For example, including at least one of A, B, and C can represent including any one or more elements selected from the set composed of A, B, and C.

[0026] In addition, for better illustration of the present disclosure, numerous specific details are given in the following detailed implementation manners. Those skilled in the art should understand that the present disclosure can also be implemented without some specific details. In some instances, methods, means, elements and circuits well-known to those skilled in the art are not described in detail so as to highlight the gist of the present disclosure.

[0027] Currently, there are mainly two ways to determine the game frame rate. First, for game developers, they can implement frame rate acquisition within the game source code. However, this method has great limitations. To obtain the game frame rates of all games, it is necessary to implement frame rate acquisition in the source codes of all games, which is unrealistic. Second, injecting a dynamic link library (DLL) file for obtaining the frame rate remotely into the game process requires separately implementing API hooks for Dx9 / Dx10 / Dx11 / Dx12 / OGL rendering-related functions. This method is universal and can obtain the frame rates of all games. However, the DLL remote injection mechanism will affect the stable operation of the game, and more and more games have added anti-injection mechanisms, making this method ineffective.

[0028] Embodiments of the present disclosure provide a method for determining the game frame rate, which can effectively and quickly determine the game frame rate without affecting the operation of the game. The method for determining the game frame rate provided by the embodiments of the present disclosure will be described in detail below.

[0029] Figure 1 The flowchart of a method for determining the game frame rate according to an embodiment of the present disclosure is shown. This method can be executed by a terminal device corresponding to the Windows operating system. The terminal device can be a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc. This method can be implemented by a processor calling computer-readable instructions stored in a memory. As Figure 1 shown, the method includes:

[0030] In step S11, the frame rate parameter of the target game process currently running is read from a preset object, where the frame rate parameter of the target game process is determined based on the UMD.

[0031] In the Windows operating system, if you want to implement a graphics card driver, you must implement the UMD and the kernel mode driver (KMD) according to the Windows Display Driver Model (WDDM) framework. In the Windows operating system, the kernel mode is the mode in which programs that handle system core functions run (for example, managing hardware, maintaining system stability, etc.). In contrast, the user mode is mainly used to run programs or drivers related to application programs. Programs in the user mode have some limitations. For example, they cannot perform physical memory mapping and call functions related to interrupt handling, while programs and drivers in the kernel mode do not have these limitations.

[0032] When the target game process starts, the running file of the target game process needs to load the UMD dynamic library so that the target game can directly call the UMD interface for rendering during the running process to implement the graphics card driver. Therefore, the frame rate parameter of the target game process can be determined based on the UMD.

[0033] In one example, based on the terminal management program (hereinafter referred to as APP), the frame rate parameter of the target game process determined based on the UMD can be read from a preset object. The APP has a game frame rate monitoring function. After the user starts the game frame rate monitoring function of the APP, the APP can communicate with the UMD and read the frame rate parameter of the game process from the preset object.

[0034] Since the APP and the UMD are different processes, it is necessary to implement the communication and data transmission between the APP and the UMD based on a preset inter-process communication method. Among them, the specific form of the preset object depends on the preset inter-process communication method between the APP and the UMD.

[0035] Later, in combination with possible implementation manners of the present disclosure, the specific form of the preset inter-process communication method, the specific form of the preset object, and the specific process of how to read the frame rate parameter of the target game process from the preset object will be described in detail, and will not be elaborated here.

[0036] In step S12, based on the frame rate parameter of the target game process, the running frame rate of the target game process is determined.

[0037] After the APP reads the frame rate parameter of the target game process determined based on the UMD from the preset object, it can quickly determine the running frame rate of the target game process. Later, in combination with possible implementation manners of the present disclosure, the specific process of how to determine the running frame rate of the target game process based on the frame rate parameter of the target game process will be described in detail, and will not be elaborated here.

[0038] In the embodiment of the present disclosure, for any game that uses the UMD to implement the graphics card driver, since the drawing and rendering during the game operation need to call the UMD interface, the frame rate parameter of the currently running target game process determined based on the UMD can be directly read from the preset object, and then the running frame rate of the target game process can be effectively and quickly determined based on the frame rate parameter of the target game process, without forcibly injecting a DLL file for obtaining the frame rate into the running target game process, and thus the running speed of the target game process will not be affected.

[0039] In addition, the game frame rate determination method provided by the embodiment of the present disclosure is universal and applicable to any game that uses the UMD to implement the graphics card driver.

[0040] In a possible implementation manner, the frame rate parameter of the target game process includes: the frame rate parameter of each rendering thread of the target game process.

[0041] The UMD can determine the frame rate parameter of each rendering thread of the target game process in units of rendering threads, so that the running frame rate of the target game process can be updated according to the frame rate parameters of different rendering threads later.

[0042] In a possible implementation, reading the frame rate parameter of the target game process currently running from a preset object includes: reading the frame rate parameter of the target game process from the preset object based on a preset inter-process communication method; when the preset inter-process communication method is shared memory, the preset object is the shared memory; when the preset inter-process communication method is one of the following: signal, pipe, Socket, message queue, the preset object is the UMD.

[0043] Since the APP and the UMD are different processes, the APP can read the frame rate parameter of the target game process currently running from the preset object based on the preset inter-process communication method. The specific form of the preset object depends on the preset inter-process communication method between the APP and the UMD.

[0044] When the preset inter-process communication method is shared memory, the preset object is the shared memory. At this time, the UMD creates the shared memory corresponding to the target game process, and this shared memory allows both the APP and the UMD to access it, so as to realize the communication between the two processes of the APP and the UMD, and further realize that the APP reads the frame rate parameter of the target game process determined based on the UMD from the shared memory.

[0045] When the preset inter-process communication method is one of the following: signal, pipe, Socket, message queue, the preset object is the UMD. At this time, the APP can directly communicate with the UMD to read the frame rate parameter of the target game process from the UMD.

[0046] In addition to being able to be one of shared memory, signal, pipe, socket (Socket), message queue, the preset inter-process communication method can also adopt other inter-process communication methods according to the actual situation, and the present disclosure does not make specific limitations thereto.

[0047] In a possible implementation, the preset object is the shared memory; the method includes: after the target game process is started, creating, based on the UMD, the shared memory corresponding to the target game process, where the shared memory is used to store the frame rate parameters of each rendering thread of the target game process.

[0048] After the target game process is started, the UMD creates the shared memory corresponding to the target game process, where the shared memory allows both the UMD and the APP to access it.

[0049] In one example, after the target game process is started, the UMD creates a shared memory corresponding to the target game process based on the process identity (PID), process name, and a preset string of the target game process. Among them, the PID and process name are used to indicate the mapping relationship between the shared memory and the target game process. Subsequently, the APP can access the shared memory corresponding to the target game process based on the PID and process name. The preset string is used to indicate that the shared memory can only be accessed by two processes, namely the APP and the UMD, to prevent other processes outside the APP and UMD from reading / writing to the shared memory and causing errors. The specific form of the preset string can be flexibly set according to the actual situation. For example, it can be a string pre-agreed by the APP and the UMD. The present disclosure does not make specific limitations on this.

[0050] Since the rendering during the operation of the target game process may include multiple rendering threads, the UMD stores the frame rate parameters of each rendering thread of the target game process in the shared memory corresponding to the target game process.

[0051] After the shared memory corresponding to the target game process is created, for any one rendering thread of the target game process, when the rendering thread calls the rendering interface based on the UMD, the UMD updates the frame rate parameter of the rendering thread in the shared memory corresponding to the target game process.

[0052] In a possible implementation, the preset object is the shared memory, and the shared memory includes a first shared memory and a second shared memory; the method further includes: after the target game process is started, based on the UMD, create a first shared memory corresponding to the target game process, where the first shared memory is used to store the thread identity (TID) and Device pointer information of each rendering thread of the target game process; according to the TID and Device pointer information corresponding to each rendering thread of the target game process, based on the UMD, create a second shared memory corresponding to each rendering thread of the target game process, where the second shared memory corresponding to each rendering thread is used to store the frame rate parameter corresponding to the rendering thread.

[0053] After the target game process is started, the UMD creates a first shared memory corresponding to the target game process and a second shared memory corresponding to each rendering thread of the target game process, so that the frame rate parameters corresponding to each rendering thread of the target game process can be updated and stored regularly based on the first shared memory and the second shared memory.

[0054] The specific process of the UMD creating the first shared memory corresponding to the target game process is similar to the specific process of the UMD creating the shared memory corresponding to the target game process described above, and will not be elaborated here.

[0055] Since the rendering during the running of the target game process may include multiple rendering threads, UMD stores the TID and Device pointer information corresponding to each rendering thread of the target game process in the first shared memory corresponding to the target game process.

[0056] Furthermore, for each rendering thread of the target game process, UMD creates a second shared memory corresponding to the rendering thread according to the TID and Device pointer information corresponding to the rendering thread, where the TID and Device pointer information corresponding to the rendering thread are used to uniquely identify the second shared memory.

[0057] For any rendering thread of the target game process, when the rendering thread calls the rendering interface based on UMD, UMD updates the frame rate parameter of the rendering thread in the second shared memory corresponding to the rendering thread.

[0058] In one example, when the game frame rate monitoring function of the APP is enabled, UMD can periodically update and write the frame rate parameter of the target game process into the corresponding shared memory; when the game frame rate monitoring function of the APP is not enabled, UMD can avoid performing the write operation of the shared memory.

[0059] In the case of multiple game processes, UMD creates the corresponding shared memory (the first shared memory and the second shared memory) for each game process, and then UMD can periodically update and store the frame rate parameter of each game process based on the shared memory corresponding to each game process, so that the subsequent APP can read the frame rate parameter of each game process from the shared memory corresponding to each game process to determine the running frame rate of each game process.

[0060] Figure 2 The schematic diagram showing a method for determining the game frame rate according to an embodiment of the present disclosure. As Figure 2 shown, there are multiple game processes from game 0 to game n, and UMD creates the corresponding shared memory for each game process to periodically update and store the frame rate parameter of each game process; the APP reads the frame rate parameter of each game process from the shared memory corresponding to each game process to determine the running frame rate of each game process. The frame rate determination processes of different game processes can be synchronized or not, and the present disclosure does not make specific limitations on this.

[0061] In a possible implementation, reading the frame rate parameter of the target game process currently running from a preset object includes: reading the TID and Device pointer information corresponding to each rendering thread of the target game process from the first shared memory; for any rendering thread of the target game process, based on the TID and Device pointer information corresponding to the rendering thread, reading the frame rate parameter of the rendering thread from the second shared memory corresponding to the rendering thread.

[0062] For the target game process currently running, the APP can determine the first shared memory corresponding to the target game process according to the PID, process name, and preset string of the target game process, so that the TID and Device pointer information corresponding to each rendering thread of the target game process can be read from the first shared memory.

[0063] After the APP reads the TID and Device pointer information corresponding to each rendering thread of the target game process, according to the TID and Device pointer information corresponding to each rendering thread, the second shared memory corresponding to each rendering thread can be determined, so that the frame rate parameter of the rendering thread can be read from the second shared memory corresponding to each rendering thread.

[0064] In a possible implementation, determining the running frame rate of the target game process based on the frame rate parameter of the target game process includes: for any rendering thread of the target game process, determining the rendering frame rate of the rendering thread based on the frame rate parameter of the rendering thread; determining the running frame rate of the target game process based on the rendering frame rates of each rendering thread of the target game process.

[0065] When determining the running frame rate of the target game process, using each rendering thread of the target game process as the determination unit, first update and determine the rendering frame rate of each rendering thread, and then update and determine the running frame rate of the target game process according to the rendering frame rates of each rendering thread.

[0066] In a possible implementation, the frame rate parameter of each rendering thread of the target game process includes: the number of thread frames at different times in the rendering thread; for any rendering thread of the target game process, determining the rendering frame rate of the rendering thread based on the frame rate parameter of the rendering thread includes: determining the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in the rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment; determining the rendering frame rate of the rendering thread based on the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in the rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment.

[0067] The UMD can update the frame rate parameter in the second shared memory corresponding to each rendering thread at regular intervals according to the actual rendering situation of each rendering thread of the target game process. The frame rate parameters stored in the second shared memory corresponding to each rendering thread include: the thread frame numbers at different times in this rendering thread, which are used to indicate the number of frames that have been rendered by this rendering thread at different times. For example, the thread frame number at the (t + 1)-th moment in the rendering thread is frameCount(t), indicating that the number of frames rendered by this rendering thread at the t-th moment is frameCount(t). The (t + 1)-th moment and the t-th moment can be two adjacent data update times, and the time difference between two adjacent data update times can be flexibly set according to the actual situation. For example, they are 100 ms apart. The present disclosure does not make specific limitations on this.

[0068] In one example, the second shared memory corresponding to each rendering thread stores: the thread frame number of this rendering thread and the corresponding timestamp information. For example, the second shared memory data at the t-th moment is {frameCount(t), ts(t)}, where frameCount(t) is the thread frame number at the t-th moment, and ts(t) is the timestamp information at the t-th moment; the second shared memory data at the (t + 1)-th moment is {frameCount(t + 1), ts(t + 1)}, where frameCount(t + 1) is the thread frame number at the (t + 1)-th moment, and ts(t + 1) is the timestamp information at the (t + 1)-th moment.

[0069] In one example, for the i-th rendering thread of the target game process, the APP can use the following formula (1) to determine the rendering frame rate FPS(i) of the i-th rendering thread:

[0070] FPS(i) = (frameCount(t + 1) - frameCount(t)) / (ts(t + 1) - ts(t)) (1).

[0071] For the i-th rendering thread of the target game process, after reading the frame rate parameters at the (t + 2)-th moment from the second shared memory corresponding to the i-th rendering thread, the rendering frame rate FPS(i) of the i-th rendering thread can be updated with reference to the above method based on the frame rate parameters at the (t + 2)-th moment and the frame rate parameters at the (t + 1)-th moment.

[0072] In one possible implementation manner, determining the running frame rate of the target game process based on the rendering frame rates of each rendering thread of the target game process includes: performing a normalization process on the rendering frame rates of each rendering thread of the target game process to obtain the running frame rate of the target game process.

[0073] After the APP determines the rendering frame rate of each rendering thread of the target game process, it performs normalization processing on the rendering frame rate of each rendering thread of the target game process, and can quickly obtain the running frame rate of the target game process.

[0074] In one example, the target game process includes n rendering threads. After the APP determines the rendering frame rate of each rendering thread, it can use the following formula (2) to determine the running frame rate FPS of the target game process:

[0075] FPS = (FPS(1) + FPS(2) + … + FPS(n)) / n (2).

[0076] Among them, FPS(1) is the rendering frame rate of the first rendering thread, FPS(2) is the rendering frame rate of the second rendering thread, and FPS(n) is the rendering frame rate of the nth rendering thread.

[0077] After the rendering frame rate of each rendering thread of the target game process is updated, the running frame rate of the target game process can be updated based on the above normalization method.

[0078] In one example, after the APP determines the running frame rate of the target game process, it can be displayed to the user in real time so that the user can monitor the game frame rate.

[0079] In the embodiments of the present disclosure, for any game that uses UMD to implement the graphics card driver, since the drawing and rendering during the game operation need to call the UMD interface, therefore, the frame rate parameter of the currently running target game process determined based on UMD can be directly read from a preset object. Furthermore, based on the frame rate parameter of the target game process, the running frame rate of the target game process can be effectively and quickly determined without forcibly injecting a DLL file for obtaining the frame rate into the running target game process, and thus the running speed of the target game process will not be affected.

[0080] It can be understood that the above-mentioned various method embodiments mentioned in the present disclosure can be combined with each other to form a combined embodiment without violating the principle logic. Due to space limitations, the present disclosure will not elaborate further. Those skilled in the art can understand that in the above methods of the specific implementation manner, the specific execution order of each step should be determined according to its function and possible internal logic.

[0081] In addition, the present disclosure also provides a game frame rate determination device, an electronic device, a computer-readable storage medium, and a program, all of which can be used to implement any game frame rate determination method provided by the present disclosure. The corresponding technical solutions and descriptions are referred to the corresponding records in the method part and will not be elaborated further.

[0082] Figure 3 The block diagram of a game frame rate determination device according to an embodiment of the present disclosure is shown. AsFigure 3 As shown in Figure 3 , device 30 includes:

[0083] A parameter reading module 31, configured to read the frame rate parameter of the target game process currently running from a preset object, where the frame rate parameter of the target game process is determined based on the UMD;

[0084] A frame rate determining module 32, configured to determine the running frame rate of the target game process based on the frame rate parameter of the target game process.

[0085] In a possible implementation manner, the frame rate parameter of the target game process includes: the frame rate parameter of each rendering thread of the target game process.

[0086] In a possible implementation manner, the parameter reading module 31 is specifically configured to:

[0087] Read the frame rate parameter of the target game process from a preset object based on a preset inter-process communication method;

[0088] When the preset inter-process communication method is shared memory, the preset object is the shared memory;

[0089] When the preset inter-process communication method is one of the following: signal, pipe, Socket, message queue, the preset object is the UMD.

[0090] In a possible implementation manner, the preset object is the shared memory;

[0091] Device 30 further includes:

[0092] A creation module, configured to create a shared memory corresponding to the target game process based on the UMD after the target game process is started, where the shared memory is used to store the frame rate parameter of each rendering thread of the target game process.

[0093] In a possible implementation manner, the preset object is the shared memory, and the shared memory includes a first shared memory and a second shared memory;

[0094] The creation module is further configured to:

[0095] After the target game process is started, create a first shared memory corresponding to the target game process based on the UMD, where the first shared memory is used to store the TID and Device pointer information of each rendering thread of the target game process;

[0096] Based on the TID and Device pointer information corresponding to each rendering thread of the target game process, create the second shared memory corresponding to each rendering thread of the target game process based on the UMD, where the second shared memory corresponding to each rendering thread is used to store the frame rate parameter of the rendering thread.

[0097] In a possible implementation, the parameter reading module 31 is specifically configured to:

[0098] Read the TID and Device pointer information corresponding to each rendering thread of the target game process from the first shared memory;

[0099] For any rendering thread of the target game process, based on the TID and Device pointer information corresponding to the rendering thread, read the frame rate parameter of the rendering thread from the second shared memory corresponding to the rendering thread.

[0100] In a possible implementation, the frame rate determination module 32 is specifically configured to:

[0101] For any rendering thread of the target game process, determine the rendering frame rate of the rendering thread based on the frame rate parameter of the rendering thread;

[0102] Based on the rendering frame rates of each rendering thread of the target game process, determine the running frame rate of the target game process.

[0103] In a possible implementation, the frame rate parameter of each rendering thread of the target game process includes: the number of thread frames at different times in the rendering thread;

[0104] The frame rate determination module 32 is specifically configured to:

[0105] Determine the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in the rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment;

[0106] Based on the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in the rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment, determine the rendering frame rate of the rendering thread.

[0107] In a possible implementation, the frame rate determination module 32 is specifically configured to:

[0108] Perform normalization processing on the rendering frame rates of each rendering thread of the target game process to obtain the running frame rate of the target game process.

[0109] This method has a specific technical association with the internal structure of the computer system, and can solve the technical problems of how to improve the hardware operation efficiency or execution effect (including reducing the data storage amount, reducing the data transmission amount, and improving the hardware processing speed, etc.), thereby obtaining the technical effect of improving the internal performance of the computer system in line with the natural law.

[0110] In some embodiments, the functions or modules included in the apparatus provided by the embodiments of the present disclosure can be used to execute the methods described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments. For the sake of brevity, it will not be repeated here.

[0111] The embodiments of the present disclosure also propose a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the above methods are implemented. The computer-readable storage medium can be a volatile or non-volatile computer-readable storage medium.

[0112] The embodiments of the present disclosure also propose an electronic device, including: a processor; a memory for storing instructions executable by the processor; wherein, the processor is configured to call the instructions stored in the memory to execute the above methods.

[0113] The embodiments of the present disclosure also provide a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code. When the computer-readable code runs in the processor of an electronic device, the processor in the electronic device executes the above methods.

[0114] The electronic device can be provided as a terminal, a server, or other forms of devices.

[0115] Figure 4 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. For example, the electronic device 800 can be a terminal device such as a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc.

[0116] Refer to Figure 4 , the electronic device 800 can include one or more of the following components: a processing component 802, a memory 804, a power component 806, a multimedia component 808, an audio component 810, an input / output interface 812, a sensor component 814, and a communication component 816.

[0117] The processing component 802 generally controls the overall operation of the electronic device 800, such as operations associated with display, telephone calls, data communication, camera operations, and recording operations. The processing component 802 can include one or more processors 820 to execute instructions to complete all or part of the steps of the above methods. In addition, the processing component 802 can include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 can include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0118] The memory 804 is configured to store various types of data to support the operation of the electronic device 800. Examples of such data include instructions for any application or method operating on the electronic device 800, contact data, phone book data, messages, pictures, videos, and the like. The memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0119] The power supply component 806 provides power to various components of the electronic device 800. The power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 800.

[0120] The multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can not only sense the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the electronic device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have focal length and optical zoom capabilities.

[0121] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC) that is configured to receive external audio signals when the electronic device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 804 or transmitted via the communication component 816. In some embodiments, the audio component 810 further includes a speaker for outputting audio signals.

[0122] The input / output interface 812 provides an interface between the processing component 802 and a peripheral interface module, and the peripheral interface module may be a keyboard, a click wheel, buttons, etc. These buttons may include, but are not limited to: a home button, a volume button, a power button, and a lock button.

[0123] The sensor component 814 includes one or more sensors for providing an assessment of various aspects of the status of the electronic device 800. For example, the sensor component 814 can detect the on / off state of the electronic device 800, the relative positioning of components, such as the display and keypad of the electronic device 800. The sensor component 814 can also detect a change in the position of the electronic device 800 or a component of the electronic device 800, the presence or absence of user contact with the electronic device 800, the orientation or acceleration / deceleration of the electronic device 800, and a change in the temperature of the electronic device 800. The sensor component 814 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor component 814 can also include a light sensor, such as a complementary metal oxide semiconductor (CMOS) or charge-coupled device (CCD) image sensor, for use in imaging applications. In some embodiments, the sensor component 814 can also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0124] The communication component 816 is configured to facilitate communication between the electronic device 800 and other devices in a wired or wireless manner. The electronic device 800 can access a wireless network based on communication standards, such as Wi-Fi, 2G, 3G, 4G, Long Term Evolution (LTE) of Universal Mobile Telecommunications Technology, 5G, or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0125] In an exemplary embodiment, the electronic device 800 can be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above method.

[0126] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 804 including computer program instructions, and the computer program instructions can be executed by a processor 820 of an electronic device 800 to complete the above method.

[0127] The present disclosure may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium having thereon computer-readable program instructions for causing a processor to implement various aspects of the present disclosure.

[0128] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, (but is not limited to) an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or raised structures in grooves having instructions stored thereon, and any suitable combination of the foregoing. The computer-readable storage medium used herein is not construed as an instantaneous signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

[0129] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded to an external computer or external storage device through a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include a copper transmission cable, an optical fiber transmission, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing / processing device.

[0130] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine - related instructions, microcode, firmware instructions, state - setting data, or source code or object code written in any combination of one or more programming languages, including object - oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer - readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand - alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, by using the state information of the computer - readable program instructions to customize an electronic circuit, such as a programmable logic circuit, a field - programmable gate array (FPGA), or a programmable logic array (PLA), the electronic circuit can execute the computer - readable program instructions to implement various aspects of the present disclosure.

[0131] Aspects of the present disclosure are described herein with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer - readable program instructions.

[0132] These computer - readable program instructions can be provided to a processor of a general - purpose computer, a special - purpose computer, or other programmable data - processing apparatus to produce a machine such that the instructions, when executed by the processor of the computer or other programmable data - processing apparatus, create a means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram. These computer - readable program instructions can also be stored in a computer - readable storage medium, which causes a computer, a programmable data - processing apparatus, and / or other devices to operate in a particular manner, so that the computer - readable medium storing the instructions comprises a manufacture, which includes instructions for implementing various aspects of the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0133] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices, causing a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other devices to produce a computer-implemented process, so that the instructions executed on the computer, other programmable data processing apparatus, or other devices implement the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0134] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0135] The computer program product may be implemented specifically by means of hardware, software, or a combination thereof. In an alternative embodiment, the computer program product is specifically embodied as a computer storage medium. In another alternative embodiment, the computer program product is specifically embodied as a software product, such as a Software Development Kit (SDK), etc.

[0136] The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments. Their similarities or likenesses can be referred to each other. For the sake of brevity, they will not be elaborated herein.

[0137] Those skilled in the art can understand that in the above methods of the specific implementation manners, the writing order of the steps does not mean a strict execution order and impose any limitation on the implementation process. The specific execution order of each step should be determined according to its function and possible internal logic.

[0138] If the technical solution of this application involves personal information, the product using the technical solution of this application has clearly informed the personal information processing rules and obtained the individual's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using the technical solution of this application has obtained the individual's separate consent before processing the sensitive personal information, and at the same time meets the "explicit consent" requirement. For example, on personal information collection devices such as cameras, clear and prominent signs are set to inform that the personal information collection scope has been entered and personal information will be collected. If the individual voluntarily enters the collection scope, it is deemed that he or she agrees to the collection of his or her personal information; or on the device that processes personal information, the personal information processing rules are notified by obvious signs / information, and the individual's authorization is obtained through pop-up information or by asking the individual to upload his or her personal information; among them, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the type of personal information processed.

[0139] The embodiments of the present disclosure have been described above, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles of the embodiments, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for determining game frame rate, characterized in that, Including: Reading the frame rate parameter of the target game process currently running from a preset object, where the frame rate parameter of the target game process is determined based on the User-Mode Driver (UMD), and the frame rate parameter of the target game process includes: the number of thread frames at different times in each rendering thread of the target game process, and the number of thread frames at different times in each rendering thread is used to indicate the number of frames that have been rendered by the rendering thread at different times; Determining the running frame rate of the target game process based on the frame rate parameter of the target game process; The determining the running frame rate of the target game process based on the frame rate parameter of the target game process includes: For any one rendering thread of the target game process, determining the rendering frame rate of the rendering thread based on the frame rate parameter of the rendering thread; Determining the running frame rate of the target game process based on the rendering frame rate of each rendering thread of the target game process.

2. The method according to claim 1, wherein The reading the frame rate parameter of the target game process currently running from a preset object includes: Reading the frame rate parameter of the target game process from the preset object based on a preset inter-process communication method; When the preset inter-process communication method is shared memory, the preset object is the shared memory; When the preset inter-process communication method is one of the following: signal, pipe, socket, message queue, the preset object is the UMD.

3. The method according to claim 1, wherein The preset object is the shared memory; The method further includes: After the target game process is started, creating the shared memory corresponding to the target game process based on the UMD, where the shared memory is used to store the frame rate parameter of each rendering thread of the target game process.

4. The method according to claim 1, wherein The preset object is the shared memory, and the shared memory includes a first shared memory and a second shared memory; The method further includes: After the target game process is started, creating the first shared memory corresponding to the target game process based on the UMD, where the first shared memory is used to store the thread ID (TID) of each rendering thread of the target game process and the rendering device (Device) pointer information; Based on the TID and Device pointer information corresponding to each rendering thread of the target game process, creating the second shared memory corresponding to each rendering thread of the target game process based on the UMD, where the second shared memory corresponding to each rendering thread is used to store the frame rate parameter of the rendering thread.

5. The method according to claim 4, characterized in that, The reading the frame rate parameter of the target game process currently running from a preset object includes: Reading the TID and Device pointer information corresponding to each rendering thread of the target game process from the first shared memory; For any one rendering thread of the target game process, reading the frame rate parameter of the rendering thread from the second shared memory corresponding to the rendering thread based on the TID and Device pointer information corresponding to the rendering thread.

6. The method according to claim 1, wherein The determining the rendering frame rate of the rendering thread based on the frame rate parameter of the rendering thread for any one rendering thread of the target game process includes: Determine the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in the rendering thread, as well as the time difference between the (t + 1)-th moment and the t-th moment; Based on the difference between the number of thread frames at the (t + 1)-th moment and the number of thread frames at the t-th moment in the rendering thread, and the time difference between the (t + 1)-th moment and the t-th moment, determine the rendering frame rate of the rendering thread.

7. The method according to claim 6, characterized in that, The determining the running frame rate of the target game process based on the rendering frame rates of each rendering thread of the target game process includes: Perform normalization processing on the rendering frame rates of each rendering thread of the target game process to obtain the running frame rate of the target game process.

8. A game frame rate determination device, characterized in that Includes: A parameter reading module, configured to read the frame rate parameters of the currently running target game process from a preset object, where the frame rate parameters of the target game process are determined based on UMD, and the frame rate parameters of the target game process include: the number of thread frames at different moments in each rendering thread of the target game process, and the number of thread frames at different moments in each rendering thread is used to indicate the number of frames that have been rendered by the rendering thread at different moments; A frame rate determining module, configured to determine the running frame rate of the target game process based on the frame rate parameters of the target game process; The frame rate determining module is specifically configured to: For any one rendering thread of the target game process, determine the rendering frame rate of the rendering thread based on the frame rate parameters of the rendering thread; Based on the rendering frame rates of each rendering thread of the target game process, determine the running frame rate of the target game process.

9. An electronic device, characterized in that, Includes: A processor; A memory for storing instructions executable by the processor; Wherein, the processor is configured to call the instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, the method according to any one of claims 1 to 7 is implemented.

Images