CN112328353B

CN112328353B - Display method and device of sub-application player, electronic equipment and storage medium

Info

Publication number: CN112328353B
Application number: CN202110013072.XA
Authority: CN
Inventors: 霍铭浩
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-01-06
Filing date: 2021-01-06
Publication date: 2021-04-27
Anticipated expiration: 2041-01-06
Also published as: CN112328353A

Abstract

The application relates to the technical field of computers, in particular to a display method and device of a sub-application player, electronic equipment and a storage medium, which are used for realizing that the control graph of a sub-application player control can be adjusted in a self-adaptive window size under any playing window size. The method comprises the following steps: when a playing window of a player draws a control graph of each player control, acquiring reference drawing parameters of the control graph corresponding to each player control adopting logic pixel layout; carrying out zooming processing according to the zooming coefficient corresponding to the size of the playing window and the reference drawing parameter corresponding to each control figure to obtain a target drawing parameter corresponding to each control figure; and re-rendering the control graphics by adopting the stack style scaling attribute according to the target drawing parameters corresponding to the control graphics. According to the method and the device, the control graph is re-rendered according to the parameter information during the layout of the logic pixels and the scaling coefficient corresponding to the size of the playing window, and the self-adaption of any size can be realized.

Description

Display method and device of sub-application player, electronic equipment and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for displaying a sub-application player, an electronic device, and a storage medium.

Background

With the continuous development of communication technology and the popularization of computer technology, various Application programs (APPs) advance to people's daily life, and sub-applications are a program that can be used without downloading and installing, and are more widely concerned by various industries. At present, APPs in various industries develop sub-applications so as to facilitate popularization and seize user traffic, and implementing audio and video playing in the sub-applications is becoming a demand of urgent implementation for people.

In the related art, when the audio/video playing function is implemented in the sub-application, an rpx (responsive pixel) layout method is generally adopted, and the screen width is defined to be 750rpx regardless of the screen size. However, this method is only suitable for the case where the player width is equal to the screen width at the mobile end, and cannot satisfy the case where the PC (personal computer) end is large or the player width is not equal to the screen width, and the control graphic layout is easily confused.

Disclosure of Invention

The embodiment of the application provides a display method and device of a sub-application player, electronic equipment and a storage medium, which are used for realizing that the control graph of a sub-application player control can be adjusted in a self-adaptive window size under any playing window size.

The display method of the sub-application player provided by the embodiment of the application comprises the following steps:

when a playing window of a player draws a control graph of each player control, acquiring reference drawing parameters of the control graph corresponding to each player control adopting logic pixel layout;

zooming according to the zooming coefficient corresponding to the size of the playing window and the reference drawing parameter corresponding to each control graph to obtain a target drawing parameter corresponding to each control graph;

and re-rendering each control graph in the playing window by adopting the stack style scaling attribute according to the target drawing parameter corresponding to each control graph.

The display device of sub-application player that this application embodiment provided includes:

the parameter acquisition unit is used for acquiring reference drawing parameters of control graphs corresponding to the player controls adopting the logic pixel layout when the control graphs of the player controls are drawn in a playing window of the player;

the parameter adjusting unit is used for carrying out zooming processing according to the zooming coefficient corresponding to the size of the playing window and the reference drawing parameter corresponding to each control figure to obtain a target drawing parameter corresponding to each control figure;

and the rendering unit is used for re-rendering each control graph in the playing window by adopting the stack style scaling attribute according to the target drawing parameter corresponding to each control graph.

Optionally, the reference drawing parameter of each control graphic includes a reference drawing parameter of each control graphic element in the control graphic; the reference drawing parameters of each control graphical element include a reference position parameter and a reference size parameter.

Optionally, the progress bar graph further includes a progress identification graphic element, where the progress identification graphic element is used to indicate a playing progress of the current target multimedia content; the device further comprises:

the adjusting unit is used for determining a corresponding adjusting position according to the visual size position information of the progress bar graph after zooming when a playing progress adjusting instruction for the progress bar graph is detected, wherein the visual size position information is determined according to the zooming coefficient and the real size position information of the progress bar graph before zooming;

updating the position of the progress identification graphic element on the progress bar graph according to the adjusting position; and

and determining the adjusted playing progress according to the adjustment position, and playing according to the adjusted playing progress.

Optionally, the apparatus further comprises: a coefficient determination unit for determining the scaling coefficient by:

and searching a scaling coefficient having a mapping relation with the size of the playing window of the player according to a preset mapping relation between the size of the playing window and the scaling coefficient, and taking the searched scaling coefficient as the scaling coefficient corresponding to the size of the playing window.

Optionally, in the mapping relationship, compared with the size of the target playing window, if only the width of the playing window of the player is increased and the height of the playing window is unchanged, the corresponding scaling factor is kept unchanged; or

Compared with the size of the target playing window, if only the height of the playing window of the player is increased and the width of the playing window is unchanged, the corresponding scaling coefficient is kept unchanged.

An electronic device provided by an embodiment of the present application includes a processor and a memory, where the memory stores a program code, and when the program code is executed by the processor, the processor is enabled to execute the steps of any one of the methods for displaying a sub-application player.

Embodiments of the present application provide a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, so that the computer device executes the steps of any one of the above-mentioned presentation methods of the multi-sub-application player.

An embodiment of the present application provides a computer-readable storage medium, which includes program code, when the program product runs on an electronic device, the program code is configured to enable the electronic device to execute the steps of the method for displaying a sub-application player.

The beneficial effect of this application is as follows:

the embodiment of the application provides a display method and device of a sub-application player, electronic equipment and a storage medium. And further determining a corresponding scaling coefficient according to the size of the playing window size of the player, determining corresponding target drawing parameters under the size of the current playing window based on the scaling coefficient and the reference drawing parameters of each control graphic, and re-rendering the control graphics of each player control based on the parameters, so that the player control in the sub-application player can be self-adapted to the size of the playing window. Based on the method, the control bar can normally operate in the players with different sizes, so that the control graphs can be normally displayed in any size of the control bar of the sub-application player, the problem of larger or smaller or disordered layout can be solved, and the control bar is not influenced by the width of a screen.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1A is a schematic view of a playing interface of a first applet player in the related art;

FIG. 1B is a schematic diagram of a playing interface of a second applet player in the related art;

fig. 2 is an alternative schematic diagram of an application scenario in an embodiment of the present application;

fig. 3 is a flowchart illustrating a method for displaying a sub-application player according to an embodiment of the present application;

FIG. 4A is a diagram of a sub-application player control bar according to an embodiment of the present application;

FIG. 4B is a diagram of another control bar of a seed application player in an embodiment of the present application;

fig. 5A is a schematic view of a playing interface of a first mobile player in the embodiment of the present application;

fig. 5B is a schematic view of a playing interface of a second mobile player in the embodiment of the present application;

fig. 5C is a schematic view of a full-screen playing interface of a mobile player in the embodiment of the present application;

fig. 6 is a schematic view of a playing interface of a PC player in the embodiment of the present application;

fig. 7 is a schematic view of a playing interface of a PC player under a full screen in an embodiment of the present application;

FIG. 8 is a schematic diagram illustrating a rendering process of a control graph according to an embodiment of the present application;

FIG. 9 is a flowchart of an adjusting method in the case of dragging interaction in the embodiment of the present application;

fig. 10 is a schematic structural diagram of a display apparatus of a sub-application player in an embodiment of the present application;

fig. 11 is a schematic diagram of a hardware component structure of a first electronic device to which an embodiment of the present application is applied;

fig. 12 is a schematic diagram of a hardware component structure of a second electronic device to which an embodiment of the present application is applied.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments, but not all embodiments, of the technical solutions of the present application. All other embodiments obtained by a person skilled in the art without any inventive step based on the embodiments described in the present application are within the scope of the protection of the present application.

Some concepts related to the embodiments of the present application are described below.

The sub-applications are as follows: the mobile terminal application program is developed based on a specific programming language and can be used without downloading and installing, and the mobile terminal application program can run on a cross-platform mobile client terminal. The sub-applications may include applets or the like that run based on the native application. The applet has the greatest characteristic of convenient use, and the user can open the application by scanning or searching without manually installing the applet in an operating system of the mobile terminal, so that the user does not need to worry about whether to install too many application programs. In addition, the applet developer can conveniently add the plug-in into the applet of the applet developer, and the service of the applet is enriched. When the user is using the applet, the services provided by the plug-ins will be available within the applet.

A player control: controls refer to the encapsulation of data and methods. The control can have its own properties and methods, wherein the properties are simple visitors of the control data, the methods are some simple and visible functions of the control, the control creating process comprises designing, developing and debugging work, and then the use of the control. The player control is a common user interface control and is used for developing and constructing a control of a playing interface and helping to complete development of interface elements such as windows, text boxes, buttons, pull-down menus and the like in software development.

Control graphics and control graphical elements: the control graphics are usually child windows of the parent frame window, which greatly enhances the usability of the program by providing a fast single-step command operation. The control graphic is a control bar, but may be other graphics, such as a circular ring shape. And the control graphic element indicates a control element in the control graphic, namely the control with the pattern. For example, a double-speed switch key, a play pause key, a definition switch key and the like in the player control bar belong to the control graphic elements.

Progress bar: that is, the speed, the completion degree, the size of the remaining unfinished tasks and the processing time possibly required by the computer when processing the tasks are displayed in real time in a picture form, and are generally displayed in a rectangular bar shape. In the embodiment of the application, the progress bar also belongs to one of the control graphs.

CSS (Cascading Style Sheets) and zoom: CSS is a computer language used to represent the style of Web (World Wide Web) files, a markup language used to (enhance) control the style of Web pages and allow separation of style information from the content of the Web pages. zoom is the scaling factor that specifies the window or viewing area according to which the CSS style is scaled, which is equivalent to a magnifying glass. The scale of the view can be changed by zoom in and zoom out operations, similar to zooming with a camera. The absolute size of the objects in the graph is not changed using zoom. It only changes the scale of the view.

rpx: the size unit of the small program image display is a size unit which can be adapted according to the screen width, is a size unit for solving the screen adaptation, can be adapted according to the screen width, and is 750rpx in terms of the screen width regardless of the size of the screen. By rpx setting the size of the elements and fonts, the applet can achieve automatic adaptation under different size screens.

px (CSS pixels, logical pixel): the logical pixel used in the CSS pattern is a relative unit, and the device pixel is opposite thereto. Also known as virtual pixels or device independent pixels, may also be understood as intuitive pixels. It is a basic unit of image display, and is neither a definite physical quantity nor a point or a small square but an abstract concept.

Cloud technology refers to a hosting technology for unifying serial resources such as hardware, software, network and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data.

Cloud technology (Cloud technology) is based on a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied in a Cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing.

The display method of the sub-application player in the embodiment of the present application can also be implemented based on a cloud technology. Specifically, each player control may be nested in a container, and the control graphics of the player controls may be scaled equally based on the container. Container technology is one application in cloud computing. Cloud computing (cloud computing) is a computing model that distributes computing tasks over a pool of resources formed by a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the "cloud" appear to the user as being infinitely expandable and available at any time, available on demand, expandable at any time, and paid for on-demand.

As a basic capability provider of cloud computing, a cloud computing resource pool (called as an ifas (Infrastructure as a Service) platform for short is established, and multiple types of virtual resources are deployed in the resource pool and are selectively used by external clients.

According to the logic function division, a PaaS (Platform as a Service) layer can be deployed on an IaaS (Infrastructure as a Service) layer, a SaaS (Software as a Service) layer is deployed on the PaaS layer, and the SaaS can be directly deployed on the IaaS. PaaS is a platform on which software runs, such as a database, a web container, etc. SaaS is a variety of business software, such as web portal, sms, and mass texting. Generally speaking, SaaS and PaaS are upper layers relative to IaaS.

The following briefly introduces the design concept of the embodiments of the present application:

taking a control graph as an example of a control bar, the sub-application player control bar is used as a tool facing the interaction between the user and the video, and when the sizes of the players presented in different terminals are different, whether the control bar can adapt to the size of the player to ensure the normality of the video content and the interactive operation is an important part in the user experience indexes.

rpx layout is a method of sub-application adaptive layout that allows the control graphics of the player controls to adapt with the width of the player. However, the method is only suitable for the situation that the mobile terminal and the player width are equal to the screen width, and cannot meet the situation that the PC terminal is large in screen or the player width is not equal to the screen width, and meanwhile, the experience problem that the dragging function error of the playing progress is large or the player cannot be used is caused.

For example, the sub-application specifies a screen width of 750 rpx. If the screen width is 375px and there are 750 physical pixels on a device, then 750rpx =375px =750 physical pixels and 1rpx =0.5px =1 physical pixel. As shown in table 1:

TABLE 1

From the above table of conversion relationships, the larger the screen, the larger the rpx scaled px value. If the width of the player exceeds 750px, the rpx layout elements in the player will be larger, and the dragging of the playing progress is influenced; if the player width is not equal to the screen width, the elements of the rpx layout within the player may be cluttered, affecting the overall interaction. For example, as shown in fig. 1A, which is a schematic diagram of a playing interface when the width of the mobile-end landscape player exceeds 750px, the control graphic element in the rpx layout is large, and the playing experience is easily affected. For example, as shown in fig. 1B, a schematic diagram of a playing interface when the width of the player on the PC side is not equal to the width of the screen is shown, and control graphic elements arranged in rpx are messy, which is easy to affect the interactive experience.

In view of this, an embodiment of the present application provides a method and an apparatus for displaying a sub-application player, an electronic device, and a storage medium. According to the method and the device, the logic pixels and the stack style scaling attributes are combined, when the logic pixels are used for layout of the control graphics, the drawing parameters corresponding to the control graphics are all fixed values, and therefore the drawing parameters of the control graphics corresponding to each player control which is laid out by the logic pixels are obtained and used as the reference drawing parameters. And further determining a corresponding scaling coefficient according to the size of the playing window size of the player, determining corresponding target drawing parameters under the size of the current playing window based on the scaling coefficient and the reference drawing parameters of each control graphic, and re-rendering the control graphics of each player control based on the parameters, so that the player control in the sub-application player can be self-adapted to the size of the playing window. Based on the method, the control bar can normally operate in the players with different sizes, so that the control graphs can be normally displayed in any size of the control bar of the sub-application player, the problem of larger or smaller or disordered layout can be solved, and the control bar is not influenced by the width of a screen.

The preferred embodiments of the present application will be described below with reference to the accompanying drawings of the specification, it should be understood that the preferred embodiments described herein are merely for illustrating and explaining the present application, and are not intended to limit the present application, and that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.

Fig. 2 is a schematic view of an application scenario according to an embodiment of the present application. The application scenario diagram includes two terminal devices 210 and a server 220. The terminal device 210 and the server 220 can communicate with each other through a communication network.

In an alternative embodiment, the communication network is a wired network or a wireless network. The terminal device 210 and the server 220 may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

In this embodiment, the terminal device 210 is an electronic device used by a user, and the electronic device may be a computer device having a certain computing capability and running instant messaging software and a website or social contact software and a website, such as a personal computer, a mobile phone, a tablet computer, a notebook, an e-book reader, a smart home, and the like. Each terminal device 210 and the server 220 are connected via a wireless Network, and the server 220 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, middleware service, a domain name service, a security service, a CDN (Content Delivery Network), a big data and an artificial intelligence platform.

Each terminal device may have a social application or a short video application installed therein, and the plurality of sub-applications may run based on the social application or the short video application. Illustratively, the terminal device 210 has an instant messaging application installed thereon, and a plurality of sub-applications may run based on the instant messaging application. The user may launch a sub-application via an instant messaging application installed on the terminal device 210. When the terminal device 210 receives an operation of starting a certain sub-application from a user, the terminal device 210 downloads data related to the sub-application from the server 220, and runs the sub-application.

The following mainly describes the display method of the sub-application player in the embodiment of the present application, taking the sub-application as an applet as an example, and taking the control graph as a player control bar as an example:

referring to fig. 3, an implementation flow chart of a method for displaying a sub-application player provided in the embodiment of the present application is shown, and a specific implementation flow of the method is as follows:

s31: when a playing window of a player draws a control graph of each player control, acquiring reference drawing parameters of the control graph corresponding to each player control adopting logic pixel layout;

in the embodiment of the application, one control graphic can be composed of a plurality of control graphic elements.

The position parameters specifically represent the distance between the control graphic element and the boundary of the playing window, the distance between the control graphic element and the adjacent control graphic element, and the like.

S32: zooming according to the zooming coefficient corresponding to the size of the playing window and the reference drawing parameter corresponding to each control graph to obtain a target drawing parameter corresponding to each control graph;

in the embodiment of the application, when the reference drawing parameter is scaled according to the scaling coefficient and the target drawing parameter corresponding to each control graphic is obtained, the target drawing parameter may be a product of the reference drawing parameter and the scaling coefficient.

Wherein the scaling factor is determined according to the size of the playing window. Generally, when the size is too small, the player can set a lower limit size, and after the size of the player exceeds a certain threshold, the player only needs to keep the control graphic elements obvious and convenient to operate, so that the blocked pictures are reduced, and the playing experience is ensured. Furthermore, a single increase in width or height dimension should keep the zoom value constant. Therefore, in the embodiment of the application, a zoom algorithm with upper and lower limits is provided to calculate the scaling factor of the control bar.

In this embodiment of the present application, a mapping relationship between the size of the playing window and the scaling factor may be preset based on the aforementioned zoom algorithm, and when the scaling factor is determined according to the size of the playing window, the scaling factor corresponding to the size of the current playing window may be searched based on the mapping relationship.

Referring to table 2, it is a table of mapping relationship between player window size and scaling factor in the embodiment of the present application.

Assuming a minimum player size of 160px by 90px (aspect ratio 16: 9), table 2 shows the width values in the horizontal direction, the height values in the vertical direction, and the cells corresponding to the width and height values of zoom. It can be seen that when width and height reach 1760px 990px (threshold), i.e., zoom value is 1.5, the control bar is not enlarged thereafter.

TABLE 2

Referring to table 2, taking the width of the playing window as 90px as an example, when the height of the playing window is 160px, 480px, 800px, 1120px, 1440px, 1760px, 2080px, the width is not changed, as the height increases, the corresponding zoom coefficient zoom value is 1, and the corresponding target playing window size is 90px × 160 px. For another example, when the height of the playing window is 160px, the heights of the playing windows are 90px, 270px, 450px, 630px, 810px, 990px, and 1170px, respectively, the heights are not changed, and as the widths are increased, the zoom coefficients zoom values are all 1, and so on.

As can be seen from the above table, in the mapping relationship listed in table 2, if the width of the playing window of the player is increased and the height of the playing window is not changed, the corresponding scaling factor is kept unchanged, compared with the size of the target playing window; or, compared with the size of the target playing window, if only the height of the playing window of the player is increased and the width of the playing window is not changed, the corresponding scaling factor is kept unchanged.

The target play window size may specifically refer to window sizes located on diagonal lines in the table, and these may be used as the target play window size. Such as: 90px × 160px, 270px × 480px, 450px × 800px, 630px × 1120px, 810px × 1440px, 990px × 1760px, 1170px × 2080 px. Here, zoom values corresponding to the sizes of these target playing windows are gradually increased, except 1170px × 2080px, so that the upper limit of the zoom value set in the embodiment of the present application is 1.5.

For example, the width of the 90px × 160px playing window is 90px, the height is 160px, and for this target playing window size, compared with the respective playing window sizes corresponding to the row with the width of 90px or the column with the height of 160px, only a single increment of width or height is added, so that the corresponding zoom values are all equal and both are 1; the 270px × 480px playback window has a width and a height that are changed from those of the 90px × 160px playback window. When 270px × 480px is used as the size of the target playing window, corresponding zoom values are equal to each other and are all 1.1 only when the height increases or the width increases, and so on, which is a similar reason, specifically refer to table 2.

Where zoom =1.5 represents magnification of 1.5 times. For example, before zooming, a control graphic element is 2px away from the lower boundary of the playing window, and after zooming by 1.5 times, the control graphic element is 3px away from the lower boundary of the playing window.

S33: and re-rendering each control graph in the playing window by adopting the stack style scaling attribute according to the target drawing parameter corresponding to each control graph.

After the target drawing parameters corresponding to each control graphic are determined, the stack style scaling attribute zoom is adopted, and each control graphic is rendered in the playing window.

In this embodiment of the application, after the stacking style zooming attribute zoom function, the space occupied by the control graphic element changes, and the positions of other control graphic elements adjacent to the control graphic element also change, so that the reference drawing parameters corresponding to the control graphic are zoomed based on the above process to obtain the target drawing parameters corresponding to each control graphic, and then the control graphic in the play window is rearranged and redrawn based on the determined target drawing parameters.

It should be noted that the presentation method of the sub application player in the embodiment of the present application may also be implemented based on a cloud technology. Specifically, each player control can be nested in a container to perform scaling and the like on the control graphics of the player controls based on the container.

In the above embodiment, a technical scheme is provided for controlling the size of the graphics adaptive player by using the px + zoom, so that elements in the control graphics can be normally displayed under any size of the control bar of the sub application player, the problem of layout that the control graphics are too large or too small or disordered does not occur, and the normal use of functions such as playing progress dragging is not affected by the width of the screen. The playing control method in the embodiment of the application can be suitable for a mobile terminal, a PC terminal and the like, is not limited by the width of a player and the width of a screen, and can meet the condition that the PC terminal is large in screen or the width of the player is not equal to the width of the screen.

In addition, it is contemplated that the control graphic can further include a progress bar graphic, which also includes an operable portion, such as a progress-identifying graphic element, and an inoperable portion, such as a start point, an end point, etc. of the progress bar. When the control graphics further include a progress bar graphic, all the control graphics can be nested in the same container, scaling is performed, and corresponding target drawing parameters are determined and re-rendered. Of course, the progress bar may also be width-adaptive.

In an optional implementation manner, when the control graph further includes a progress bar graph, the step S32 is implemented based on the following process, which specifically includes:

respectively re-rendering other control graphs in the playing window by adopting the stack style scaling attribute according to target drawing parameters corresponding to other control graphs except the progress bar graph; and re-rendering the progress bar graph in the playing window by adopting the stack style scaling attribute according to the space occupied by each other control graph in the playing window and the target drawing parameter corresponding to the progress bar graph.

In the embodiment of the present application, when a user opens an applet player, a terminal device responds to a trigger operation for opening the player, and at this time, a control graph of each player control in a player playing window may be rendered in a px + zoom manner as set forth in the embodiment of the present application. In addition, for the progress bar graph, width self-adaptation may be performed based on the space occupied by other control graphs, for example, after scaling is simply performed, the total length of the progress bar is 600px, but apart from other control graphs, some space is actually left for operation, and at this time, self-adaptation adjustment may be performed, for example, the total length of the progress bar is adjusted to 650 px.

The progress bar in the playing window obtained by rendering based on the above embodiment is also subjected to width self-adaptation on the basis of zooming, which is beneficial to reducing the error of the dragging function of the playing progress.

In the embodiment of the application, there are two situations that the control graphics of each player control need to be drawn in the playing window of the player, one is when the applet starts to run, and the other is when the state of the playing window of the player changes in the running process of the applet, and in this situation, each control graphic in the playing window needs to be re-rendered according to the size of the changed playing window.

The rendering process in the first case is first described in detail below:

when a user opens the applet player, the terminal device responds to a trigger operation of opening the player, at the moment, a px layout player control bar (control-bar) element is used in the range of the player, a cascading style scaling attribute zoom is used in an outer layer, and a progress bar (progress-bar) adopts width self-adaptation. The names of key parts of the control bar in the applet static template are shown below in conjunction with fig. 4A and 4B, along with sample code.

The sample code is as follows:

< view id = "control bar" class = "control-bar" style- "zoom: { { zoom } } ">/denotes that the view ID is: control bar (control bar), class name: control-bar, attributes are: zoom attribute, zoom in { { zoom } } represents a specific scaling coefficient, such as 1.1

< | where the Play-pause button is omitted- - ]

<view

class = "progress"/denotes a class name: progress, i.e. the following is a definition for a progress bar

catch touch Start = "on Progress Start"/touch Start = process Start

catch touch Move = "on Progress Move"/touch in = Progress

catch touch End = 'on Progress End'/touch End = process End

>

<! -duration played >

<text class="played-time">{{playedTime}</text>

< | progress >

< | progress Bar >

< | Total progress Bar >

< | buffered progress Bar >

<! -progress bar played >

< | played small dots- - >)

< | Total duration >

<text class="total - time">{{total Time} } /text>

</view>

< | the speed multiplier button is omitted here >

< | the clarity button is omitted here >

< | where full screen button is omitted- - ]

</view>

The code represents that the zoom attribute zoom acts on a control bar control-bar through a cascading style, wherein the player control comprises: play-pause button, progress bar, speed-doubling button, sharpness button, full screen button, etc. The specific code is for the control bar, and the detailed definition of the progress bar within the control bar, the definition of the play-pause button, the double speed button, the sharpness button, the full screen button, etc. are not described in detail herein. The definition of the progress bar specifically includes touch (such as dragging), played time length, progress (indicating playing progress), a progress bar (used for indicating the current playing progress), a total progress bar (corresponding to the total playing time length), a buffered progress bar (used for indicating the progress of the currently buffered portion), a total time length (indicating the total playing time length), and the like.

In this embodiment of the present application, the control graphics corresponding to different player controls include one or more control graphics elements, for example, the play graphics in the play-pause button includes two control graphics elements, as shown in S40 in fig. 4A, which show the play graphics indicating the current play state, and the pause graphics includes one control graphics element, as shown in S43 in fig. 4B, which show the pause graphics indicating the current pause state, and when the play-pause button is clicked in the current state, the play state can be switched to the play state, and after the switch, the play graphics is switched to the pause state, as shown in fig. 4A; as shown in S41 in fig. 4A, the full screen button includes two control graphic elements, and the progress bar graphic includes a plurality of control graphic elements. The speed-doubling button and the definition button each include a control graphic element, for example, the control graphic element of the speed-doubling button is "1.0 ×" in fig. 4A, the control graphic element of the definition button is "high definition" in fig. 4A, and so on.

Specifically, progress-bar also belongs to a control graph in a control bar, and the progress-bar graph has a plurality of control graph elements, including an operable part, namely, a "played dot" listed in the above code, for identifying the current playing progress; in addition, the system also comprises an inoperable part: such as a total progress bar, a buffered progress bar, a total duration, etc.

In the embodiment of the present application, after the overlay style scaling attribute zoom is applied, the space occupied by the control graphic element changes, and the positions of other control graphic elements adjacent to the control graphic element also change, so that the control graphic element is rearranged and redrawn by using the control bar.

Fig. 5A and 5B are schematic diagrams of playing interfaces of two mobile end players listed in the embodiment of the present application. Fig. 5A is a schematic view showing a playing interface of the player when the width of the player is equal to the width of the mobile terminal screen; FIG. 5B is a schematic diagram showing a playing interface of the player when the width of the player is not equal to the width of the mobile terminal screen.

As can be seen from the two diagrams, the display method of the sub-application player in the embodiment of the present application is applicable to the case where the player width is equal to the screen width at the mobile end, and also applicable to the case where the player width is greater than the screen width at the mobile end.

Fig. 5C is a schematic view of a playing interface of a mobile terminal player in a full screen in the embodiment of the present application; as can be seen from fig. 5C, in a full screen (horizontal screen) state of the mobile end, the width of the player is equal to the width of the mobile end, and is actually greater than the width of the mobile end screen, and compared to the situation that the elements are disordered when the width of the screen is greater than the width of the player in the related art, the method in the embodiment of the present application can render the elements in the playing window, which are not disordered and can be normally displayed when the width of the player is greater than the width of the screen at the mobile end.

Fig. 6 is a schematic view of a playing interface of a PC player according to an embodiment of the present application; obviously, when the control graphics in the playing window are rendered based on the display method of the sub-application player in the embodiment of the application, although the size of the screen of the PC end is large, the player can still be adapted when the width of the screen is large, the control graphics displayed in the playing window do not have the condition of disordered elements, and the overall interaction is not influenced.

Fig. 7 is a schematic diagram of a playing interface of a PC player in a full screen in the embodiment of the present application; in the full screen state, the width of the player screen is equal to the size of the PC side screen. In the related art, because the screen size of the PC end is large, when the PC end plays in a full screen, the width of the player exceeds 750px, the elements in the rpx layout in the player are large, and the dragging of the playing progress is affected. Obviously, the display method based on the sub-application player in the embodiment of the present application can be applied to a large screen at a PC end or a case where the player width is not equal to the screen width, in addition to being applicable to a mobile end.

In summary, the display method of the sub-application player in the embodiment of the application solves the problems that elements in a control bar of a small program player can be normally displayed under any size, the layout problem of being larger or smaller or disordered can not occur, the functions such as the dragging of the playing progress can be normally used, and the influence of the width of a screen can not be caused.

The rendering process in the second case is described in detail below:

in an alternative embodiment, before step S31 is executed, it is also necessary to monitor the status change of the playing window during the running of the sub-application; and when the change of the state of the playing window is monitored, determining that the control graphics of each player control are required to be drawn in the playing window of the player.

The change of the direction of the playing window is generally triggered by the rotation of the screen by the user, and the playing window can be enlarged or reduced when the user rotates the screen. The change in the size of the playback window is typically triggered by the user adjusting the window size, such as the user selecting 100% of the screen, 75%, full screen (full screen), etc.

In the embodiment of the application, when the applet runs, after the player control bar generates and joins the view, the applet window changes (including window size adjustment, screen rotation, full screen, etc.) are monitored. When the window changes, the control bar is re-rendered. Specifically, the process of re-rendering the control bar is shown in fig. 8.

Fig. 8 is a schematic diagram illustrating a rendering flow of a control graph in the embodiment of the present application, which describes a detailed process when a control bar is re-rendered under a condition that a state of a play window changes. The specific implementation flow of the method is as follows:

first, at the time of applet running, a player control bar is generated and added (attached) to the view using the rendering process in the first case enumerated above. Then the listening window changes (xx. onwindowresize), a process "when created" shown in fig. 8. When the state of the playing window is monitored to be changed, the control graphs of the player controls are determined to be redrawn in the adjusted playing window. Specifically, the redrawing process is the process "rendering time" shown in fig. 8. Finally, the listening window change is stopped when the applet uninstalls (exits the applet) (xx.

The process of the middle column "render-time" of FIG. 8 is described in detail below:

when the control bar is re-rendered, firstly inquiring the view information of the control bar, retrying if the inquiry is failed, and if the inquiry is successful, calculating a zoom value by adopting a zoom algorithm based on the inquired view information of the control bar, and setting the zoom value to update the view; inquiring progress bar view information; and calculating the scaled virtual progress bar model information.

The control bar view information comprises reference position information, reference size information and the like of graphic elements of each control in the control bar; based on the queried control bar view information, in conjunction with table 2, the zoom value is recalculated.

In the embodiment of the present application, when calculating the zoom value, there may be a case where the zoom before and after calculation is not changed, for example, the size of the playing window before change is 270px wide and 480px high; the size of the changed playing window is 450px wide and 480px high. Compared with the size of the playing window before change, only the height is changed, and the width is not changed. As can be seen from the lookup table 2, before and after the change, the zoom values are all 1.1, and in this case, the position and the size of each control graphic element in the play window are not changed, that is, the size parameter is not changed, but the position parameter is changed.

When calculating the changed corresponding target position parameters, the width of the changed playing window needs to be further combined in addition to the reference position parameters and the zoom coefficients zoom corresponding to the control graphics.

For example, the window width before change is 270px, the height is 480px, the corresponding zoom value is 1.1, and the distance between the control graphic element a and the control graphic element B is 3.3 px. The width of the window after the change is 450px, the height is 480px, and the corresponding zoom value is 1.1, at this time, the size of the control graphic element does not change because the zoom values before and after the change are not changed, but the zoom values corresponding to the playing windows before and after the change are changed, so the position of the control graphic element in the control bar can be further changed, for example, the distance between the control graphic element a and the control graphic element B is increased to 5.5px to adapt to the change of the width of the playing window.

In addition, when recalculating the zoom value, the zoom value may be changed before and after the change calculation, and may be increased or decreased. Generally, when zoom is larger, the size of the corresponding playback window is larger, and when zoom is smaller, the size of the corresponding playback window is smaller. For example, the size of the playing window before change is 270px wide and 480px high; the size of the changed playing window is 450px wide and 800px high. Both width and height are changed compared to the size of the play window before the change. As can be seen from table 2, the before-change zoom value is 1.1, and the after-change zoom value is 1.2. In this case, the influence is that the position and size of each control graphic element in the playing window, namely, the size parameter and the position parameter are changed.

For example, in the case of no scaling, that is, zoom =1, the control figure element a and the control figure element B are both circles, the radii are both 1px, and the distance between the control figure element a and the control figure element B is 3 px. Then the radius of both control graphical elements is 1.1px and the distance is 3.3px in the case of zoom =1.1, and 1.2px and the distance is 3.6px in the case of zoom = 1.2. Similarly, the same reasoning applies when the zoom value becomes smaller, and this is not listed here.

With reference to the above, in this embodiment of the application, when the control graph further includes a progress bar graph, the progress bar graph also needs to be re-rendered in the play window, and the specific process is as follows:

acquiring a reference drawing parameter corresponding to a progress bar graph when the progress bar graph is arranged by adopting a logic pixel; determining target drawing parameters corresponding to the zoomed progress bar graph according to the zoom coefficient and the reference position parameter and the reference size parameter corresponding to the progress bar graph; and re-rendering the progress bar graph in the playing window according to the target drawing parameters corresponding to the progress bar graph and the current playing progress.

As can be seen from the above process, the process of rendering the progress bar graph is similar to that of rendering other control graphs, but the rendering of the progress bar graph is also related to the current playing progress. In addition, the virtual progress bar model information after scaling, that is, the target drawing parameters in the embodiment of the present application, needs to be calculated by means of the virtual progress bar model.

It should be noted that the virtual progress bar model established in the embodiment of the present application is used for converting the progress after zooming when dragging interaction. In the applet, the cascading style scaling attribute zoom visually enlarges elements in the control bar, particularly the progress bar, but actually queries the real size of the progress bar, but the real size is smaller than the visual size. Specifically, the following calculation relationship exists between the visual size position and the real size position of the progress bar: zoom progress bar visual size position = zoom value x progress bar true size position.

Therefore, in the embodiment of the present application, a virtual model needs to be established in the memory, and the size and position of the zoom-out progress bar are recorded, so that the progress value can be correctly calculated when the user drags the progress bar to position in the subsequent interaction.

In an optional implementation manner, the progress bar graph further includes a progress identification graphic element, and the progress identification graphic element is used for indicating the playing progress of the current target multimedia content. In addition, the user can also adjust the playing progress by dragging the button corresponding to the progress identification graphic element. It should be noted that other adjustment manners besides dragging are also possible, and the dragging is mainly taken as an example for illustration herein, and is not specifically limited herein. When the small program runs, after the progress bar is generated and added into the view, monitoring the interaction actions of a user and the progress bar, wherein the actions comprise starting dragging (touchstart), dragging (touchmove) and ending dragging (touchend).

Because the drag data generated during user interaction is based on the zoom visual size position, the embodiment of the present application needs to calculate the progress according to the zoom progress bar visual size position. Specifically, when a playing progress adjusting instruction for a progress bar graph is detected, a corresponding adjusting position is determined according to visual size position information of a zoomed progress bar graph, wherein the visual size position information is determined according to a zooming coefficient and real size position information of the zoomed progress bar graph; updating the position of the progress identification graphic element on the progress bar graph according to the adjustment position; and determining the adjusted playing progress according to the adjustment position, and playing according to the adjusted playing progress.

Fig. 9 is a flowchart illustrating an adjusting method under the dragging interaction condition in the embodiment of the present application. The specific implementation flow of the method is as follows:

and if the fact that the user starts to drag the button corresponding to the progress identification graphic element is detected, starting to record the dragging process, recording the dragging position in the dragging process of the user, and calculating the progress according to the zoom progress bar visual dimension position information. And if the new progress obtained after the progress is calculated is within an effective range of 0-100%, directly updating the visual progress without correcting the progress boundary. If the calculated new progress is not in the effective range of 0% -100%, correcting the progress boundary, and if the new progress is closer to 0%, correcting the progress boundary to 0% and updating the visual progress; if the new progress is closer to 100%, the correction is 100%, and the visual progress is updated.

And after the user cancels the dragging, identifying the distance between the position of the graphic element and the initial position of the progress bar according to the progress after canceling the dragging, executing (playing) progress searching according to the percentage of the distance in the whole progress bar, and playing according to the searched progress, namely the adjusted playing progress.

In summary, the px + zoom technology in the embodiment of the present application brings the beneficial effect that the control bar of the applet player is adaptive to the size of the player, the technology can avoid the problem of poor interaction experience caused by too small control bar elements in a large-size player, and simultaneously, the disadvantage that the control bar elements are disordered when the width of the player is not equal to the width of the screen by adopting the rpx adaptive method in the related technical scheme is solved.

Based on the same inventive concept, the embodiment of the application also provides a display device of the sub-application player. As shown in fig. 10, it is a schematic structural diagram of a display apparatus 1000 of a sub application player, and may include:

a parameter obtaining unit 1001, configured to obtain, when a play window of a player draws a control graphic of each player control, a reference drawing parameter of a control graphic corresponding to each player control adopting a logical pixel layout;

a parameter adjusting unit 1002, configured to perform scaling processing according to a scaling coefficient corresponding to the size of the play window and a reference drawing parameter corresponding to each control graphic, to obtain a target drawing parameter corresponding to each control graphic;

and a rendering unit 1003, configured to re-render each control graphic in the play window by using the stack style scaling attribute according to the target drawing parameter corresponding to each control graphic.

Optionally, the rendering unit 1003 is specifically configured to:

respectively re-rendering other control graphs in the playing window by adopting the stack style scaling attribute according to target drawing parameters corresponding to other control graphs except the progress bar graph; and

and re-rendering the progress bar graph in the playing window by adopting the stack style scaling attribute according to the space occupied by each other control graph in the playing window and the target drawing parameter corresponding to the progress bar graph.

Optionally, the apparatus further comprises:

a monitoring unit 1004, configured to monitor a state change of a playing window in a running process of the sub application before the parameter obtaining unit 1001 draws a control graph of each player control in the playing window of the player, where the state change of the playing window includes one or more of a size change of the playing window and a direction change of the playing window;

and when the change of the state of the playing window is monitored, determining that the control graphics of each player control are required to be drawn in the playing window of the player.

Optionally, the rendering unit 1003 is further configured to:

acquiring a reference drawing parameter corresponding to a progress bar graph when the progress bar graph is arranged by adopting a logic pixel;

determining target drawing parameters corresponding to the zoomed progress bar graph according to the zoom coefficient and the reference position parameter and the reference size parameter corresponding to the progress bar graph;

and re-rendering the progress bar graph in the playing window according to the target drawing parameters corresponding to the progress bar graph and the current playing progress.

Optionally, the progress bar graph further includes a progress identification graphic element, where the progress identification graphic element is used to indicate a playing progress of the current target multimedia content; the device still includes:

an adjusting unit 1005, configured to, when a play progress adjustment instruction for the progress bar graph is detected, determine a corresponding adjustment position according to visual size position information of the post-zoom progress bar graph, where the visual size position information is determined according to a zoom coefficient and real size position information of the pre-zoom progress bar graph;

updating the position of the progress identification graphic element on the progress bar graph according to the adjustment position; and

Optionally, the apparatus further comprises: a coefficient determination unit 1006, configured to determine a scaling coefficient by:

and searching a scaling coefficient having a mapping relation with the size of the playing window of the player according to the preset mapping relation between the size of the playing window and the scaling coefficient, and taking the searched scaling coefficient as the scaling coefficient corresponding to the size of the playing window.

Optionally, in the mapping relationship, compared with the size of the target playing window, if only the width of the playing window of the player is increased and the height of the playing window is not changed, the corresponding scaling factor is kept unchanged; or

Compared with the size of the target playing window, if only the height of the playing window of the player is increased and the width of the playing window is not changed, the corresponding scaling coefficient is kept unchanged.

For convenience of description, the above parts are separately described as modules (or units) according to functional division. Of course, the functionality of the various modules (or units) may be implemented in the same one or more pieces of software or hardware when implementing the present application.

After the presentation method and apparatus of the sub application player according to the exemplary embodiment of the present application are introduced, an electronic device according to another exemplary embodiment of the present application is introduced next.

As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method or program product. Accordingly, various aspects of the present application may be embodied in the form of: an entirely hardware embodiment, an entirely software embodiment (including firmware, microcode, etc.) or an embodiment combining hardware and software aspects that may all generally be referred to herein as a "circuit," module "or" system.

The electronic equipment is based on the same inventive concept as the method embodiment, and the embodiment of the application also provides the electronic equipment. The electronic device may be used for transfer control of resource objects. In one embodiment, the electronic device may be a server, such as server 220 shown in FIG. 2. In this embodiment, the electronic device may be configured as shown in fig. 11, and include a memory 1101, a communication module 1103, and one or more processors 1102.

A memory 1101 for storing computer programs executed by the processor 1102. The memory 1101 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, a program required for running an instant messaging function, and the like; the storage data area can store various instant messaging information, operation instruction sets and the like.

The memory 1101 may be a volatile memory (volatile memory), such as a random-access memory (RAM); the memory 1101 may also be a non-volatile memory (non-volatile memory), such as a read-only memory (rom), a flash memory (flash memory), a hard disk (HDD) or a solid-state drive (SSD); or the memory 1101 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such. The memory 1101 may be a combination of the above memories.

The processor 1102 may include one or more Central Processing Units (CPUs), a digital processing unit, and the like. The processor 1102 is configured to implement the display method of the sub application player when calling the computer program stored in the memory 1101.

The communication module 1103 is used for communicating with the terminal device and other servers.

In the embodiment of the present application, a specific connection medium among the memory 1101, the communication module 1103, and the processor 1102 is not limited. In fig. 11, the memory 1101 and the processor 1102 are connected by a bus 1104, the bus 1104 is shown by a thick line in fig. 11, and the connection manner between other components is merely illustrative and not limited. The bus 1104 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 11, but this is not intended to represent only one bus or type of bus.

The memory 1101 stores a computer storage medium, and the computer storage medium stores computer-executable instructions for implementing the presentation method of the sub application player according to the embodiment of the present application. The processor 1102 is configured to execute the presentation method of the sub application player, as shown in fig. 3.

In another embodiment, the electronic device may also be other electronic devices, such as the terminal device 210 shown in fig. 2. In this embodiment, the structure of the electronic device may be as shown in fig. 12, including: communications assembly 1210, memory 1220, display unit 1230, camera 1240, sensors 1250, audio circuitry 1260, bluetooth module 1270, processor 1280, and the like.

The communication component 1210 is configured to communicate with a server. In some embodiments, a WiFi (Wireless Fidelity) module may be included, the WiFi module belongs to a short-distance Wireless transmission technology, and the electronic device may help the user to send and receive information through the WiFi module.

The memory 1220 may be used for storing software programs and data. The processor 1280 performs various functions of the terminal device 210 and data processing by executing software programs or data stored in the memory 1220. The memory 1220 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid-state storage device. The memory 1220 stores an operating system that enables the terminal device 210 to operate. The memory 1220 may store an operating system and various application programs, and may also store codes for executing the presentation method of the application player according to the embodiment of the present application.

The display unit 1230 may also be used to display a Graphical User Interface (GUI) of information input by or provided to the user and various menus of the terminal apparatus 210. Specifically, the display unit 1230 may include a display screen 1232 provided on the front surface of the terminal device 210. The display 1232 may be configured in the form of a liquid crystal display, a light emitting diode, or the like. The display unit 1230 may be configured to display a sub-application playing interface in the embodiment of the present application.

The display unit 1230 may be further configured to receive input numeric or character information and generate signal input related to user settings and function control of the terminal device 210, and specifically, the display unit 1230 may include a touch screen 1231 disposed on the front surface of the terminal device 210 and configured to collect touch operations of a user thereon or nearby, such as clicking a button, dragging a scroll box, and the like.

The touch screen 1231 may cover the display screen 1232, or the touch screen 1231 and the display screen 1232 may be integrated to implement the input and output functions of the terminal device 210, and after the integration, the touch screen may be referred to as a touch display screen for short. The display unit 1230 in this application can display the application programs and the corresponding operation steps.

The camera 1240 may be used to capture still images, and the user may transmit the images taken by the camera 1240 to the user of the chat correspondent through the client. The number of the cameras 1240 may be one or plural. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing elements convert the light signals into electrical signals, which are then passed to a processor 1280 for conversion into digital image signals.

The terminal device may further comprise at least one sensor 1250, such as an acceleration sensor 1251, a distance sensor 1252, a fingerprint sensor 1253, a temperature sensor 1254. The terminal device may also be configured with other sensors such as a gyroscope, barometer, hygrometer, thermometer, infrared sensor, light sensor, motion sensor, and the like.

The audio circuit 1260, speaker 1261, microphone 1262 can provide an audio interface between a user and the terminal device 210. The audio circuit 1260 may transmit the received electrical signal converted from the audio data to the speaker 1261, and the audio signal is converted into a sound signal by the speaker 1261 and output. The terminal device 210 may also be provided with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 1262 converts the collected sound signals into electrical signals, which are received by the audio circuit 1260 for conversion into audio data, which is then output to the communication assembly 1210 for transmission to, for example, another terminal device 210, or to the memory 1220 for further processing.

The bluetooth module 1270 is used for information interaction with other bluetooth devices having bluetooth modules through a bluetooth protocol. For example, the terminal device may establish a bluetooth connection with a wearable electronic device (e.g., a smart watch) that is also equipped with a bluetooth module through the bluetooth module 1270, so as to perform data interaction.

The processor 1280 is a control center of the terminal device, connects various parts of the entire terminal device using various interfaces and lines, and performs various functions of the terminal device and processes data by running or executing software programs stored in the memory 1220 and calling data stored in the memory 1220. In some embodiments, processor 1280 may include one or more processing units; the processor 1280 may also integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a baseband processor, which primarily handles wireless communications. It is to be appreciated that the baseband processor described above may not be integrated into the processor 1280. In the application, the processor 1280 may run an operating system, an application program, a user interface display and a touch response, and the display method of the sub-application player according to the embodiment of the application. Additionally, processor 1280 is coupled with display unit 1230.

In some possible embodiments, various aspects of the presentation method of the sub application player provided by the present application may also be implemented in the form of a program product including program code for causing a computer device to perform the steps of the presentation method of the sub application player according to various exemplary embodiments of the present application described above in this specification when the program product is run on the computer device, for example, the computer device may perform the steps as shown in fig. 3.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The program product of embodiments of the present application may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a computing device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with a command execution system, apparatus, or device.

A readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with a command execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: a mobile storage device, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Alternatively, the integrated unit in the embodiment of the present application may be stored in a computer-readable storage medium if it is implemented in the form of a software functional module and sold or used as a stand-alone product. Based on such understanding, the technical solutions of the embodiments of the present application may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. It is therefore intended that the following appended claims be interpreted as including the preferred embodiment and all such alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present application without departing from the spirit and scope of the application. Thus, if such changes and modifications of the present application fall within the scope of the claims of the present application and their equivalents, the present application is intended to include such changes and modifications.

Claims

1. A display method of a sub-application player is characterized by comprising the following steps:

when a playing window of a personal computer terminal application player draws a control graph of each player control, obtaining reference drawing parameters of the control graph corresponding to each player control adopting logic pixel layout, wherein the sub-applications are nested in the native application;

according to the target drawing parameters corresponding to each control graph, re-rendering each control graph in the playing window by adopting a stack style zoom attribute zoom;

when the control graphics further include a progress bar graphic, re-rendering each control graphic in the playing window by using a stack style zoom attribute zoom according to a target drawing parameter corresponding to each control graphic, specifically including:

respectively re-rendering other control graphs in the playing window by adopting a stack style scaling attribute according to target drawing parameters corresponding to other control graphs except the progress bar graph; and

and re-rendering the progress bar graph in the playing window by adopting a stack style scaling attribute zoom according to the space occupied by each other control graph in the playing window and the target drawing parameter corresponding to the progress bar graph.

2. The method of claim 1, wherein the reference drawing parameters of each control graphic comprise reference drawing parameters of respective control graphic elements in the control graphic; the reference drawing parameters of each control graphical element include a reference position parameter and a reference size parameter.

3. The method of claim 1, wherein prior to drawing the control graphic for each player control at the player window of the player, further comprising:

monitoring the state change of the playing window in the running process of the sub-application, wherein the state change of the playing window comprises one or more of the size change of the playing window and the direction change of the playing window;

and when the state of the playing window is monitored to be changed, determining that the control graphics of each player control are required to be drawn in the playing window of the player.

4. The method of claim 1, wherein the re-rendering the control graphic in the playback window further comprises:

obtaining a reference drawing parameter corresponding to the progress bar graph when the progress bar graph is laid out by adopting the logic pixels;

determining a target drawing parameter corresponding to the progress bar graph after zooming according to the zooming coefficient, and a reference position parameter and a reference size parameter corresponding to the progress bar graph;

5. The method of claim 4, wherein the progress bar graph further includes a progress-identifying graphical element thereon, the progress-identifying graphical element being used for indicating a playing progress of the target multimedia content at present; the method further comprises the following steps:

when a playing progress adjusting instruction for the progress bar graph is detected, determining a corresponding adjusting position according to the visual size position information of the zoomed progress bar graph, wherein the visual size position information is determined according to the zoom coefficient and the real size position information of the progress bar graph before zooming;

6. The method of any one of claims 1 to 5, wherein the scaling factor is determined by:

7. The method of claim 6, wherein in the mapping relationship, if only the width of the playing window of the player is increased and the height of the playing window is unchanged compared to the size of the target playing window, the corresponding scaling factor is kept unchanged; or

8. A display device for a sub-application player, comprising:

the device comprises a parameter acquisition unit, a parameter selection unit and a parameter selection unit, wherein the parameter acquisition unit is used for acquiring reference drawing parameters of control graphics corresponding to each player control in a logic pixel layout when a playing window of a personal computer terminal sub application player draws the control graphics of each player control, and the sub applications are nested in a native application;

the rendering unit is used for re-rendering each control graph in the playing window by adopting the cascading style scaling attribute zoom according to the target drawing parameter corresponding to each control graph;

when the control graph further includes a progress bar graph, the rendering unit is specifically configured to:

9. The apparatus of claim 8, wherein the reference drawing parameters of each control graphic comprise reference drawing parameters of respective control graphic elements in the control graphic; the reference drawing parameters of each control graphical element include a reference position parameter and a reference size parameter.

10. The apparatus of claim 8, wherein the apparatus further comprises:

the monitoring unit is used for monitoring the state change of the playing window in the running process of the sub-application before the parameter acquisition unit draws the control graphics of each player control in the playing window of the player, wherein the state change of the playing window comprises one or more of the size change of the playing window and the direction change of the playing window;

11. The apparatus of claim 8, wherein the rendering unit is further to:

12. An electronic device, comprising a processor and a memory, wherein the memory stores program code which, when executed by the processor, causes the processor to perform the steps of the method of any of claims 1 to 7.

13. A computer-readable storage medium, characterized in that it comprises program code for causing an electronic device to carry out the steps of the method according to any one of claims 1 to 7, when said program code is run on said electronic device.