Display methods, devices, electronic devices, and computer program products

Abstract

This application discloses a display method, apparatus, electronic device, and computer program product, applicable to the field of computer technology. The display method is applied to a display device where a container is created within the HarmonyOS operating system. The container encapsulates the Linux operating system's runtime environment and deploys applications. The display method includes: acquiring a display data stream output by the container, the display data stream including an application identifier and window data corresponding to each of at least two functional windows generated by the application; determining at least two extended functional components associated with the application identifier from a preset set of extended functional components; and displaying at least two display windows based on the at least two extended functional components. This method solves the problem that the HarmonyOS operating system cannot directly recognize and process multi-window screen data output by the container, thus only supporting the display of a single application window and unable to simultaneously display multiple functional windows.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a display method, device, electronic device and computer program product. Background Technology

[0002] With the development of multi-operating system integration technology, existing operating systems now support running applications from other operating systems via containerization. For example, in HarmonyOS, an isolated container can be created that encapsulates the Linux operating system's runtime environment, deploying Linux applications within the container, thus enabling the running of Linux applications within HarmonyOS. However, because HarmonyOS and the Linux operating system within the container have independent window management and display rendering architectures, HarmonyOS cannot directly recognize and process the multi-window screen data output by the container, thus only supporting the display of a single application window and unable to simultaneously display multiple functional windows. Summary of the Invention

[0003] This application provides a display method, apparatus, electronic device, and computer program product that can solve the problem that the HarmonyOS operating system cannot directly recognize and process multi-window screen data output by the container, thus only supporting the display of a single application window and unable to display multiple functional windows simultaneously.

[0004] In a first aspect, embodiments of this application provide a display method applied to a display device. The display device has a container created within its HarmonyOS operating system. The container encapsulates the runtime environment of a Linux operating system and deploys an application. The display method includes: acquiring a display data stream output by the container, the display data stream including an application identifier of the application and window data corresponding to each of at least two functional windows generated by the application; determining at least two extended functional components associated with the application identifier from a preset set of extended functional components, each extended functional component being configured to process window data corresponding to a functional window; and displaying at least two display windows based on the at least two extended functional components. Specifically, a first display window in the at least two display windows displays a window image output by the first extended functional component rendering the window data corresponding to the first functional window in the at least two functional windows; and a second display window in the at least two display windows displays a window image output by the second extended functional component rendering the window data corresponding to the second functional window in the at least two functional windows.

[0005] In some possible implementations of the embodiments of this application, the above-mentioned displaying at least two display windows based on at least two extended functional components includes: obtaining a native window object associated with each extended functional component based on at least two extended functional components; rendering window data corresponding to the functional window processed by each extended functional component through each extended functional component to obtain rendering data corresponding to each window data; inputting the rendering data corresponding to the functional window processed by each extended functional component into the native window object associated with each extended functional component; and displaying at least two display windows through the native window object associated with each extended functional component.

[0006] In some possible implementations of this application, before performing the step of determining at least two extended functional components associated with the application identifier from a preset set of extended functional components based on the application identifier, the display method further includes: obtaining application window configuration information output by the container, the application window configuration information including the application identifier of the application, and the window identifier and window attribute information of each functional window in at least two functional windows supported by the application; the application window configuration information is output by the container when the application is installed; creating an extended functional component corresponding to each functional window based on the window attribute information of each functional window; establishing and storing the association relationship between the application identifier, the window identifier of each functional window, and the extended functional components corresponding to each functional window, to obtain a preset set of extended functional components.

[0007] In some possible implementations of the embodiments of this application, after performing the step of creating an extended functional component corresponding to each functional window based on the window attribute information of each functional window, the above display method further includes: determining the display surface of each functional window based on the window attribute information of each functional window; and creating a native window object associated with each functional window according to the display surface of each functional window.

[0008] In some possible implementations of the embodiments of this application, a first remote desktop service component is deployed in the HarmonyOS operating system runtime environment, and a second remote desktop service component is deployed in the container; the above display method further includes: receiving a first input from a user, the first input being an input to start an application; responding to the first input, inputting the application startup information corresponding to the first input into the second remote desktop service component through the first remote desktop service component, the second remote desktop service component being configured to start the application according to the application startup information; and, when the application is started, obtaining the display data stream output by the container.

[0009] In some possible implementations of this application's embodiments, a first remote desktop service component is deployed in the HarmonyOS operating system's runtime environment, and a second remote desktop service component is deployed in the container. The aforementioned acquisition of the display data stream output by the container includes: receiving a second input from the user, the second input being an input to a target display window in at least two display windows; responding to the second input, inputting the display screen update information corresponding to the second input into the second remote desktop service component through the first remote desktop service component; the second remote desktop service component being configured to update the window data of the functional window corresponding to the target display window according to the display screen update information; and acquiring the display data stream output by the container based on the updated window data of the functional window corresponding to the target display window through the first remote desktop service component.

[0010] In some possible implementations of this application's embodiments, a first remote desktop service component is deployed in the HarmonyOS operating system's runtime environment, a second remote desktop service component is deployed in the container, and a window composition component is deployed in the container. The above display method further includes: receiving a third input from a user, the third input being an input to adjust the display resolution of a target display window in at least two display windows; responding to the third input, inputting the display resolution adjustment information corresponding to the third input into the second remote desktop service component through the first remote desktop service component, the second remote desktop service component being configured to input the display resolution adjustment information into the window composition component, and the window composition component being configured to adjust the display resolution of the target functional window corresponding to the target display window according to the display resolution adjustment information; obtaining the adjusted window attribute information output by the second remote desktop service component through the first remote desktop service component, the adjusted window attribute information being determined based on the adjusted display resolution of the target functional window; and adjusting the display resolution of the display window corresponding to the target functional window through the adjusted window attribute information.

[0011] Secondly, embodiments of this application provide a display device applied to a display equipment. The display equipment has a container created within its HarmonyOS operating system. The container encapsulates the runtime environment of a Linux operating system and deploys applications. The display device includes: a first acquisition module, which acquires a display data stream output by the container. The display data stream includes an application identifier of the application and window data corresponding to each of at least two functional windows generated by the application; a first determination module, configured to determine at least two extended functional components associated with the application identifier from a preset set of extended functional components, wherein each extended functional component is configured to process window data corresponding to a functional window; and a display module, configured to display at least two display windows based on the at least two extended functional components. The first display window in the at least two display windows displays a window image output by the first extended functional component rendering the window data corresponding to the first functional window in the at least two functional windows; the second display window in the at least two display windows displays a window image output by the second extended functional component rendering the window data corresponding to the second functional window in the at least two functional windows.

[0012] Thirdly, embodiments of this application provide an electronic device, the display device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements a display method as described in any of the first aspects.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the display method as described in any of the first aspects.

[0014] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the display method as described in any of the first aspects.

[0015] The display method, apparatus, electronic device, computer-readable storage medium, and computer program product of this application embodiment can acquire display data streams of multiple functional windows of an aggregated application output by a container, so as to identify and distinguish each functional window of the application content; then, by using the application identifier in the display data stream, an extended functional component is determined for each functional window of the application to specifically process the window data of that functional window, so that the HarmonyOS can perform independent data processing for each functional window inside the container; subsequently, by performing independent rendering processing on the extended functional component allocated to each functional window, the adapted window data can be transformed into a window screen that can be displayed by a display window that can be natively managed by the HarmonyOS, so that the functional windows of the Linux operating system deployed in the container can achieve multi-window synchronous display, effectively solving the problem that the HarmonyOS cannot directly identify and process the multi-window screen data output by the container, thus only supporting the display of a single application window. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a display method provided in some embodiments of this application is shown; Figure 2 This paper illustrates a layout diagram of the functional windows within a container in a display method provided by some embodiments of this application; Figure 3 The illustration shows a flowchart of creating a preset extended function component set in a display method provided in some embodiments of this application; Figure 4 This paper illustrates a flowchart of the process for creating a native window object in a display method provided by some embodiments of this application; Figure 5 The present application provides a system architecture diagram of a display device in a display method according to some embodiments; Figure 6 The diagram illustrates a specific implementation of step 130 provided in some embodiments of this application; Figure 7 The diagram illustrates the layout of the display window of the HarmonyOS operating system in some embodiments of the present application. Figure 8 The diagram illustrates a flowchart of the display method for obtaining display data streams provided in some embodiments of this application. Figure 9A flowchart illustrating a specific implementation of step 110 provided in some embodiments of this application is shown; Figure 10 The diagram illustrates a flowchart of adjusting the display resolution of a display window in a display method provided in some embodiments of this application. Figure 11 The present application provides schematic diagrams of the structure of a display device according to some embodiments; Figure 12 The diagram shows a schematic representation of the structure of an electronic device provided in some embodiments of this application. Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0020] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0021] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0022] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first provides a detailed description of the relevant technologies involved: In existing multi-operating system integration technologies, when HarmonyOS runs Linux applications via containerization, the independent window management and rendering architectures of HarmonyOS and the Linux operating system within the container lead to incompatibility in window data formats and management mechanisms. This prevents HarmonyOS from directly recognizing and processing multi-window screen data output by the container, thus only supporting the display of a single application window and preventing the simultaneous display of multiple functional windows. For example, when a user runs a Personal Computer (PC) application within a container using a HarmonyOS display device, the PC application deployed within the container generates two functional windows: a browser window and a text editor window. However, the container's output display data stream includes display data for both functional windows. HarmonyOS's window manager can only recognize the identifier of a single functional window; the data for the remaining windows is ignored or overwritten. Consequently, when a user attempts to simultaneously manipulate data in both the browser and text editor windows, the display device can only show the screen of one functional window, and the screen of the other functional window cannot be activated or displayed.

[0023] To address the problems in the aforementioned related technologies, embodiments of this application provide a display method, apparatus, electronic device, and computer program product. The following description, in conjunction with the appendix, illustrates these aspects. Figure 1 To be continued Figure 10 The display method provided in this application will be described in detail through specific embodiments and application scenarios.

[0024] The display method provided in this application is applied to a display device. The display device's HarmonyOS operating system contains containers that encapsulate the Linux operating system's runtime environment and deploy applications. The display device refers to a hardware device with display capabilities and running the HarmonyOS operating system, which may include, but is not limited to, smartphones, tablets, personal computers, smart vehicle systems, and smart TVs. This display device is configured to execute the display method described in any embodiment of this application.

[0025] HarmonyOS, also known as OpenHarmony, is an open-source distributed operating system incubated and operated by the OpenAtom Foundation. HarmonyOS is configured to create and manage containers to support the execution of heterogeneous applications within them. Containers are an operating system-level resource isolation mechanism that uses kernel namespace technology to create independent virtual environments for processes, allowing processes in different containers to have isolated system resources. The container encapsulates a Linux operating system runtime environment to isolate and run Linux applications, ensuring that Linux applications execute in an independent environment.

[0026] Linux is an open-source Unix-like operating system whose runtime environment is encapsulated in containers. Within this environment, applications are deployed and executed to generate corresponding display data streams. An application is a software program deployed within the Linux operating system's runtime environment of a container. During execution, this application can generate one or more functional windows and output corresponding window data.

[0027] In some embodiments of this application, a container can be created within the HarmonyOS operating system using containerization technology, and a complete Ubuntu base image can be embedded within this container. An isolated Linux runtime environment can be built within this container using the `chroot` command. Within this Ubuntu environment, the Weston window compositor can be used to run and manage PC applications with multi-window functionality. The PC application and the Weston window compositor can communicate using the Wayland protocol to transmit window data and exchange control commands. Then, the application's graphical interface rendered by the Weston window compositor is transmitted to the HarmonyOS operating system in real time via the Free Remote Desktop Protocol (FreeRDP). Finally, the HarmonyOS operating system receives the RDP video stream transmitted via FreeRDP and, utilizing its own graphics compositing capabilities and the ArkUI framework, reorganizes and lays out the multiple functional windows of the received application, ultimately presenting them on the display device.

[0028] It's worth noting that Weson is the official reference implementation of the Wayland protocol. It's a lightweight component that provides a full-featured Wayland window compositor and display server. Furthermore, it offers both a basic desktop environment and a fully functional non-desktop application environment, adapting to the application runtime requirements of different scenarios.

[0029] FreeRDP is a free and open-source implementation of the Remote Desktop Protocol (RDP), allowing users to connect to and control remote computers running Windows or other compatible operating systems. FreeRDP is cross-platform, running smoothly on Linux, macOS, Windows, and Android. It not only supports the latest RDP protocol standards (including versions 8.0 / 8.1), but also integrates advanced features such as Network Level Authentication (NLA), remote desktop gateway, and multimedia redirection to improve the security and stability of remote connections.

[0030] Based on this Figure 1 A flowchart illustrating a display method provided in some embodiments of this application is shown. For example... Figure 1 As shown, the display method may include steps 110 to 130.

[0031] Step 110: Obtain the display data stream output by the container. The display data stream includes the application identifier of the application and the window data corresponding to each of the at least two functional windows generated by the application. Step 120: Based on the application identifier, determine at least two extended functional components associated with the application identifier from a preset set of extended functional components. Each extended functional component is configured to process the window data corresponding to a functional window. Step 130: Based on the at least two extended functional components, display at least two display windows. The first display window in the at least two display windows displays the window image output by the first extended functional component in the at least two functional windows after rendering the window data corresponding to the first functional window in the at least two functional windows. The second display window in the at least two display windows displays the window image output by the second extended functional component in the at least two functional windows after rendering the window data corresponding to the second functional window in the at least two functional windows.

[0032] Therefore, by acquiring the display data streams of multiple functional windows of the aggregated application output by the container, the various functional windows of the application content can be identified and distinguished. Then, by using the application identifier in the display data stream, an extended functional component is determined for each functional window of the application to specifically handle the window data of that functional window. This allows the HarmonyOS to perform independent data processing for each functional window inside the container. Subsequently, by performing independent rendering processing on the extended functional component assigned to each functional window, the adapted window data can be transformed into a window screen that can be displayed by the display window that the HarmonyOS can natively manage. This enables the functional windows of the Linux operating system deployed in the container to achieve multi-window synchronous display, effectively solving the problem that the HarmonyOS cannot directly identify and process the multi-window screen data output by the container, thus only supporting the display of a single application window.

[0033] The steps described above are explained in detail below.

[0034] First, regarding step 110, the application identifier involved in this embodiment is an identifier used to uniquely identify a specific application to distinguish different applications. A function window refers to an independent display area generated by an application during runtime. An application can generate multiple function windows, each carrying specific functions or content of the application. Window data refers to the display content data of the function window. It is understood that window data needs to be processed and rendered before it can be presented as a visual image on a display device.

[0035] In this step, after the application launches within the container, it creates Function Window 1 and Function Window 2. To adapt to the application's multi-window display environment, the application automatically adjusts the size and position of Function Window 1 and Function Window 2 according to preset window layout rules. Specifically, as follows... Figure 2 As shown, function window 1 and function window 2 can be adjusted to occupy the left and right halves of the corresponding display area of ​​the application, respectively, forming a side-by-side layout.

[0036] It is worth noting that the preset window layout rules can be flexibly set according to screen resolution, user preferences or application type, and this application embodiment does not limit them.

[0037] Secondly, regarding step 120, an extended functional component is a software module configured to process the window data corresponding to a functional window. Each extended functional component is designed to specifically process the data of a functional window and render it into a window display that can be shown in the HarmonyOS operating system. For example, it can be implemented using the XComponent component.

[0038] The preset extended function component set pre-stores the association between the application identifier of the application and the component identifier of the extended function component, as well as the association between the extended function component and the function window.

[0039] In this step, when the application identifier of the application is obtained, a preset set of extended functional components is first queried to obtain at least two extended functional components associated with the application identifier. Then, based on the association between the extended functional components and the functional window, the extended functional components used to process the window data of each functional window are selected from the at least two extended functional components.

[0040] In some embodiments of this application, before step 120, a process of creating a preset set of extended functional components is also included. Based on this, before step 120, such as... Figure 3 As shown, the display method includes steps 1401 to 1403, as detailed below.

[0041] Step 1401: Obtain the application window configuration information output by the container. The application window configuration information includes the application identifier of the application, and the window identifier and window attribute information of each of the at least two functional windows supported by the application. The application window configuration information is output by the container when the application is installed.

[0042] Among them, the application window configuration information is the information output by the container after parsing the application's window configuration information when the application is installed.

[0043] In one example, after the application is installed, the container can send application window configuration information to the window management service on the HarmonyOS operating system side through a specific API interface.

[0044] In another example, when the window management service on the HarmonyOS operating system side detects a new application installation or startup, it can request and obtain the application window configuration information by calling the query interface provided by the container.

[0045] Step 1402: Based on the window attribute information of each functional window, create the extended functional component corresponding to each functional window.

[0046] The window attribute information may include, but is not limited to: the size (i.e., width and height), position (i.e., X and Y coordinates), pixel format, and transparency of the function window.

[0047] In this step, by utilizing the window property information of the function window to create extended function components corresponding to each function window, it can be ensured that the created extended function components can accurately adapt to and effectively process the display data of the function window.

[0048] Step 1403: Establish and store the application identifier, the window identifier of each functional window, and the association relationship between the extended functional components corresponding to each functional window, to obtain a preset extended functional component set.

[0049] In this step, when an application is installed in a container, the HarmonyOS operating system actively or passively obtains the application's window configuration information. Using the window attribute information within the configuration, HarmonyOS can create corresponding extended functional components for each functional window, ensuring that each extended functional component can accurately process its associated functional window data. The application identifier, the window identifiers of each functional window, and the relationships between the corresponding extended functional components are established and stored, forming a structured set of pre-defined extended functional components. Thus, when multiple windows of an application need to be displayed, the display device can retrieve all associated extended functional components from the pre-defined set based on the application identifier in the received display data stream. These extended functional components then render the window data of their respective functional windows, ultimately presenting multiple independent display windows on the display device through native window objects.

[0050] Therefore, by obtaining the application window configuration information output by the container during the application installation phase, and creating and storing the association between extended functional components and application identifiers and functional window identifiers based on the application window configuration information, a complete set of preset extended functional components is constructed. This ensures that when the application is running, the HarmonyOS can quickly and accurately determine and call the corresponding extended functional components to process the multi-functional window data output by the container based on the application identifier, thereby realizing the parallel rendering and display of multi-functional windows.

[0051] In some embodiments of this application, after performing step 1402 as described above, such as Figure 4 As shown, the above display method may further include steps 1404 and 1405.

[0052] Step 1404: Determine the display surface of each functional window based on the window attribute information of each functional window.

[0053] The display surface refers to the memory area used to store window pixel data. The display screen stores the graphical content of the visible portion of the functional window on the display device.

[0054] In this step, a buffer with the appropriate size and pixel format can be allocated in graphics memory based on the window attribute information of the function window, serving as the rendering target for that function window. For example, a graphics buffer can be requested as a display surface by calling the API provided by the graphics subsystem of the HarmonyOS operating system, based on the window attribute information.

[0055] Step 1405: Create the native window object associated with each function window according to the display surface of each function window.

[0056] Native window objects are entities used at the operating system level to manage and display windows. Native window objects can be provided by the operating system's window management services and are associated with a specific display surface.

[0057] In this step, when an extended functional component in the HarmonyOS is created to handle specific functional window data from the container, HarmonyOS uses the window attribute information of that functional window to calculate and allocate a dedicated display surface as a graphics buffer for that functional window, used to hold the rendered pixel data. Subsequently, based on this determined display surface, a corresponding native window object is created in the window management framework of HarmonyOS. In this way, the window image data rendered by the extended functional component can be directly written to its associated display surface, and ultimately presented on the display device through the native window object bound to that display surface.

[0058] Specifically, such as Figure 5 As shown, an application launcher and management component (AppLauncher) can be installed within the HarmonyOS operating system. AppLauncher creates corresponding extended functional components for each functional window from the container, such as XComponent 1 and XComponent 2. Each extended functional component corresponds to an independently drawable UI component within the HarmonyOS ArkUI framework and can generate its underlying display surface. This display surface is passed by AppLauncher to the HarmonyOS underlying layer (native layer) to create corresponding native window objects, namely NativeWindow 1 associated with XComponent 1 and NativeWindow 2 associated with XComponent 2. NativeWindow is the underlying display entity directly managed by the HarmonyOS display framework, representing an independent drawing area on the display device, possessing its own graphics buffer, and is uniformly scheduled by the window manager.

[0059] Therefore, by determining the display surface that precisely matches the function window based on the window attribute information of each function window, and creating an associated native window object according to the display surface, the data rendered by the extended function component can be directly bound to the operating system-level display entity, thereby realizing independent rendering and output of each function window and supporting the simultaneous display of multiple windows.

[0060] Furthermore, regarding step 130, the display window refers to the window actually presented to the user in the HarmonyOS operating system. Each display window corresponds to a functional window screen that is processed and rendered by the extended functional components.

[0061] In this step, each extended functional component independently performs a rendering operation after receiving its corresponding functional window data, converting the window data into displayable image data. This image data is directly written to the display buffer pre-allocated by the HarmonyOS operating system, with each extended functional component corresponding to an independent display buffer. The display manager of the HarmonyOS operating system is configured to read image data from these independent display buffers and present it on the display device to form an independent display window.

[0062] In some embodiments of this application, to achieve simultaneous display of multiple application windows within a container, such as... Figure 6 As shown, step 130 above may specifically include steps 1301 to 1303.

[0063] Step 1301: Obtain the native window object associated with each of the at least two extended functional components.

[0064] The native window object is the underlying display entity provided by the HarmonyOS display framework and can be directly managed by the HarmonyOS window manager. For example, it can be a NativeWindow.

[0065] Step 1302: Render the window data corresponding to the function window processed by each extended function component through each extended function component, and obtain the rendering data corresponding to each window data.

[0066] Window data refers to the graphical output stream generated by the application within the container for a specific functional window. Rendered data, on the other hand, is processed image data that can be directly used for display. This rendering process can be completed by the rendering engine within the extended functional components or by a dedicated rendering engine within the HarmonyOS operating system.

[0067] Step 1303: Input the rendering data corresponding to the function window processed by each extended function component into the native window object associated with each extended function component, and display at least two display windows through the native window object associated with each extended function component.

[0068] For example, rendering data can be input into its associated native window object. After receiving the rendering data, the native window object performs composition through the window manager of the HarmonyOS operating system and finally presents it on the display device. For example, Figure 5 and Figure 7As shown, the window data of each functional window is submitted to the corresponding extended functional component. For example, the window data of functional window 1 transmitted from the FreeRDP server is submitted to XComponent 1 via the FreeRDP client. The rendering engine within XComponent 1 renders the window data of functional window 1 and then inputs it into the buffer of NativeWindow 1. Similarly, the window data of functional window 2 is submitted to XComponent 2. The rendering engine within XComponent 2 renders the window data of functional window 2 and then inputs it into the buffer of NativeWindow 2. Furthermore, the rendering data carried by NativeWindow 1 and NativeWindow 2 is used as... Figure 7 The independent display windows 1 and 2 shown are displayed on the display device, and the user can perform input operations such as moving, scaling, and stacking display windows 1 and 2.

[0069] Therefore, by assigning a dedicated extended functional component and native window object to each functional window, multiple functional windows of an application within the container can be treated and managed as independent display entities. Specifically, each functional window of the application within the container can be provided with an independent rendering and display path, effectively solving the problem that the HarmonyOS operating system cannot directly recognize and process multi-window screen data output by the container. This ensures that each functional window can be accurately and efficiently rendered and displayed as an independent display window, realizing the simultaneous display of multiple functional windows.

[0070] In some embodiments of this application, a first remote desktop service component is deployed in the HarmonyOS operating system environment. The first remote desktop service component is a software module deployed in the HarmonyOS operating system environment, such as... Figure 5 The FreeRDP client shown in the image deploys a second remote desktop service component in a container, such as... Figure 5 The FreeRDP server shown; the first and second remote desktop service components are used to establish remote desktop communication between the HarmonyOS operating system and the container. Based on this, as... Figure 8 As shown, the above display method may further include steps 1501 to 1503.

[0071] Step 1501: Receive the user's first input, which is the input to start the application.

[0072] For example, users can select and launch applications by clicking the application icon on the HarmonyOS desktop, by using voice commands, or by using other input devices.

[0073] Step 1502: In response to the first input, the application startup information corresponding to the first input is input to the second remote desktop service component through the first remote desktop service component, and the second remote desktop service component is configured to launch the application according to the application startup information.

[0074] The application startup information may include, but is not limited to: the application's path, name, and startup parameters.

[0075] In this step, the first remote desktop service component encapsulates application startup information into remote desktop protocol data packets and transmits them to the second remote desktop service component via IPC mechanisms such as network sockets or shared memory. Upon receiving the application startup information, the second remote desktop service component can call the system APIs within the Linux container to start the specified application process.

[0076] Step 1503: With the application running, obtain the display data stream output by the container.

[0077] In this step, after the application starts successfully, the second remote desktop service component can listen to the application's graphical output and encode this graphical data into a display data stream format supported by the remote desktop protocol, and output it to the HarmonyOS operating system.

[0078] Furthermore, a first remote desktop service component is deployed in the HarmonyOS operating system's runtime environment, and a second remote desktop service component is deployed within the container. When a user requests to launch an application via a first input, the first remote desktop service component in the HarmonyOS environment captures the first input and converts it into application launch information. This first remote desktop service component is used to transmit this application launch information to the second remote desktop service component inside the container. Upon receiving the application launch information, the second remote desktop service component launches the corresponding application within the container based on the application launch information. Once the application successfully launches and begins running, the second remote desktop service component actively or passively captures the display output generated by the application, encapsulates it into a display data stream, and then transmits the display data stream back to the HarmonyOS operating system via the first remote desktop service component. After obtaining the display data stream output from the container, the display data stream includes the application identifier of the application and the window data corresponding to each of the at least two functional windows generated by the application. The HarmonyOS operating system determines at least two extended functional components associated with the application identifier from a preset set of extended functional components, one of which is configured to process the window data corresponding to a functional window. The HarmonyOS operating system obtains the native window object associated with each of at least two extended functional components. Through each extended functional component, it renders the window data corresponding to the functional window processed by that component, obtaining the rendering data for that functional window. Finally, it inputs the rendering data for each functional window processed by each extended functional component into the native window object associated with that component, and displays at least two display windows through that native window object.

[0079] This ensures that the display data stream output by the container can be accurately obtained after the application starts, providing an accurate data source for subsequently determining extended functional components based on the application identifier and displaying at least two display windows, thus effectively supporting the simultaneous display of multi-functional windows of applications within the container under the HarmonyOS operating system environment.

[0080] In some embodiments of this application, in order to update and obtain the window's display data stream in real time, such as Figure 9 As shown, the step of obtaining the display data stream output by the container in step 110 or step 1503 may specifically include steps 1101 to 1103.

[0081] Step 1101: Receive the user's second input, which is an input to the target display window in at least two display windows.

[0082] For example, the user's second input may be a touch operation such as clicking, swiping, or long-pressing on the target display window through the touch screen of the display device; or a mouse operation such as clicking, dragging, or scrolling on the target display window through the mouse; or an input operation such as entering characters or commands through the keyboard.

[0083] Here, after recognizing the second input, the HarmonyOS operating system will associate the second input with a specific target display window.

[0084] Step 1102: In response to the second input, the display screen update information corresponding to the second input is input into the second remote desktop service component through the first remote desktop service component; the second remote desktop service component is configured to update the window data of the function window corresponding to the target display window according to the display screen update information.

[0085] The information displayed on the screen may include, but is not limited to, the type, coordinates, and status of the input event.

[0086] In this step, the first remote desktop service component can encapsulate the display update information into a remote desktop protocol data packet and transmit it to the second remote desktop service component via IPC mechanisms such as network sockets or shared memory. Upon receiving the display update information, the second remote desktop service component parses the information and updates the window data of the function window corresponding to the target display window in the application running inside the container according to its content.

[0087] For example, if the screen update information indicates a mouse click event, the second remote desktop service component will inject the click event into the Linux application's event queue, causing the application to process the event and update its internal window data.

[0088] Step 1103: Obtain the display data stream of the container based on the updated window data output of the functional window corresponding to the target display window through the first remote desktop service component.

[0089] For example, the second remote desktop service component on the container side can output the updated display data stream to the first remote desktop service component.

[0090] Therefore, when a user makes a second input to a specific display window, the HarmonyOS operating system can promptly capture and process this second input, prompting the application within the container to update the window data of the corresponding functional window, thereby obtaining the updated display data stream and presenting it on the corresponding display window. This improves the smoothness and real-time performance of multi-window interaction between the user and containerized applications.

[0091] In some embodiments of this application, the container deploys a window composition component. Within the container's Linux runtime environment, this window composition component can handle graphics rendering and window management for applications within the container independently of the host operating system. Specifically, it can be as follows: Figure 5 As shown, Weston, deployed inside the container, manages the graphics surfaces and rendering of applications within the container. This window composition component can be a virtual display server provided by the container runtime environment, simulating a display device and handling all graphics output. The composed image data stream is then transmitted to the first remote desktop service component via a second remote desktop service component within the container. Based on this, as... Figure 10 As shown, the above display method may further include steps 1601 to 1604.

[0092] Step 1601: Receive a third input from the user, which is an input to adjust the display resolution of the target display window in at least two display windows.

[0093] For example, the user's second input may be an input whereby the user adjusts the display resolution of the target display window by performing touch operations such as clicking, swiping, or long-pressing on the touch screen of the display device; or an input whereby the user adjusts the display resolution of the target display window by performing mouse operations such as clicking, dragging, or scrolling on the target display window; or an input operation where the user adjusts the display resolution of the target display window by entering characters or commands on the keyboard.

[0094] Here, after recognizing the third input, the HarmonyOS operating system will associate the third input with a specific target display window.

[0095] Step 1602: In response to the third input, the display resolution adjustment information corresponding to the third input is input to the second remote desktop service component through the first remote desktop service component. The second remote desktop service component is configured to input the display resolution adjustment information into the window composition component. The window composition component is configured to adjust the display resolution of the target function window corresponding to the target display window according to the display resolution adjustment information.

[0096] Step 1603: Obtain the adjusted window attribute information output by the second remote desktop service component through the first remote desktop service component. The adjusted window attribute information is determined based on the adjusted display resolution of the target function window.

[0097] In this process, after the window composition component adjusts the display resolution of the target function window, the second remote desktop service component will query the display resolution of the function window, encapsulate these latest display resolutions into window property update messages, and send them back to the first remote desktop service component via the remote desktop protocol.

[0098] Step 1604: Adjust the display resolution of the display window corresponding to the target function window using the adjusted window attribute information.

[0099] In this step, after receiving the adjusted window attribute information, the window manager in the HarmonyOS operating system will reconfigure the size, scaling ratio, or rendering area of ​​the target display window based on this adjusted window attribute information, so that it matches the actual display resolution of the functional windows inside the container.

[0100] Therefore, by deploying a window composition component within the container and combining it with the collaborative work between the first and second remote desktop service components, real-time and dynamic adjustment of the resolution of specific display windows by the user is achieved. This allows users to flexibly adjust the display resolution of each functional window according to actual needs and the characteristics of the display device, thereby optimizing the display effect of the device.

[0101] Based on the display method provided in the above embodiments, this application also provides specific implementations of the display device. Please refer to the following embodiments.

[0102] See Figure 11 The display device 200 provided in this application embodiment is applied to a display device. The HarmonyOS operating system of the display device creates a container, which encapsulates the running environment of the Linux operating system and deploys applications. It includes a first acquisition module 201, a first determination module 202, and a display module 203.

[0103] The first acquisition module 201 is used to acquire the display data stream output by the container. The display data stream includes the application identifier of the application and the window data corresponding to each of the at least two functional windows generated by the application. The first determination module 202 is used to determine at least two extended functional components associated with the application identifier from a preset set of extended functional components. Each extended functional component is configured to process the window data corresponding to a functional window. The display module 203 is used to display at least two display windows based on the at least two extended functional components. The first display window in the at least two display windows displays the window image output by the first extended functional component in the at least two functional windows after rendering the window data corresponding to the first functional window in the at least two functional windows. The second display window in the at least two display windows displays the window image output by the second extended functional component in the at least two functional windows after rendering the window data corresponding to the second functional window in the at least two functional windows.

[0104] Therefore, the first acquisition module 201 can acquire the display data stream of multiple functional windows of the aggregated application output by the container to identify and distinguish the various functional windows of the application content. Then, the first determination module 202 uses the application identifier in the display data stream to determine an extended functional component that specifically processes the window data of each functional window of the application, so that the HarmonyOS can perform independent data processing for each functional window inside the container. Subsequently, the display module 203 performs independent rendering processing on the extended functional component allocated to each functional window, which can transform the adapted window data into a window screen that can be displayed by the display window that the HarmonyOS can natively manage. This enables the functional windows of the Linux operating system deployed in the container to achieve multi-window synchronous display, effectively solving the problem that the HarmonyOS cannot directly identify and process the multi-window screen data output by the container, thus only supporting the display of a single application window.

[0105] In some embodiments of this application, the display module 203 described above can be specifically used to: obtain a native window object associated with each extended functional component based on at least two extended functional components; render window data corresponding to the functional window processed by each extended functional component through each extended functional component to obtain rendering data corresponding to each window data; input the rendering data corresponding to the functional window processed by each extended functional component into the native window object associated with each extended functional component, and display at least two display windows through the native window object associated with each extended functional component.

[0106] In some embodiments of this application, the display device 200 in the embodiments of this application may further include a second acquisition module, a first creation module, and a second determination module.

[0107] The second acquisition module is used to acquire application window configuration information output by the container before performing the step of determining at least two extended functional components associated with the application identifier from a preset set of extended functional components based on the application identifier. The application window configuration information includes the application identifier of the application, and the window identifier and window attribute information of each functional window in the at least two functional windows supported by the application. The application window configuration information is output by the container when the application is installed. The first creation module is used to create an extended functional component corresponding to each functional window based on the window attribute information of each functional window. The second determination module is used to establish and store the application identifier, the window identifier of each functional window, and the association relationship between the extended functional components corresponding to each functional window to obtain a preset set of extended functional components.

[0108] In some embodiments of this application, the display device 200 in the embodiments of this application may further include a third determining module and a second creating module.

[0109] The third determining module is used to determine the display surface of each functional window based on the window attribute information of each functional window; the second creating module is used to create the native window object associated with each functional window according to the display surface of each functional window.

[0110] In some embodiments of this application, a first remote desktop service component is deployed in the HarmonyOS operating system environment, and a second remote desktop service component is deployed in the container; the above-mentioned display device 200 may also include a first receiving module, a first response module, and a third acquisition module.

[0111] The first receiving module is used to receive the user's first input, which is the input to start the application; the first response module is used to respond to the first input and input the application startup information corresponding to the first input to the second remote desktop service component through the first remote desktop service component, and the second remote desktop service component is configured to start the application according to the application startup information; the third acquisition module is used to acquire the display data stream output by the container when the application is started.

[0112] In some embodiments of this application, a first remote desktop service component is deployed in the HarmonyOS operating system runtime environment, and a second remote desktop service component is deployed in the container; the aforementioned first acquisition module is specifically used for: receiving a second input from the user, the second input being an input to a target display window in at least two display windows; responding to the second input, inputting the display screen update information corresponding to the second input into the second remote desktop service component through the first remote desktop service component; the second remote desktop service component is configured to update the window data of the functional window corresponding to the target display window according to the display screen update information; and obtaining the display data stream output by the container based on the updated window data of the functional window corresponding to the target display window through the first remote desktop service component.

[0113] In some embodiments of this application, a first remote desktop service component is deployed in the HarmonyOS operating system environment, a second remote desktop service component is deployed in the container, and a window composition component is deployed in the container. The display device 200 may also include a second receiving module, a second response module, a fourth acquisition module, and an adjustment module.

[0114] The second receiving module receives a third input from the user, which is an input to adjust the display resolution of the target display window in at least two display windows. The second responding module responds to the third input by inputting the display resolution adjustment information corresponding to the third input into the second remote desktop service component through the first remote desktop service component. The second remote desktop service component is configured to input the display resolution adjustment information into a window composition component, which is configured to adjust the display resolution of the target functional window corresponding to the target display window according to the display resolution adjustment information. The fourth obtaining module obtains the adjusted window attribute information output by the second remote desktop service component through the first remote desktop service component. The adjusted window attribute information is determined based on the adjusted display resolution of the target functional window. The adjusting module adjusts the display resolution of the display window corresponding to the target functional window based on the adjusted window attribute information.

[0115] The various modules of the display device 200 provided in this application embodiment can realize Figure 1 It provides the functionality for each step of the display method and achieves the corresponding technical effects. For the sake of brevity, it will not be elaborated here.

[0116] Figure 12 The diagram shows a schematic representation of the hardware structure of an electronic device provided in some embodiments of this application.

[0117] The electronic device may include a processor 301 and a memory 302 storing computer program instructions.

[0118] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0119] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 302 may include removable or non-removable (or fixed) media. Where appropriate, memory 302 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 302 is non-volatile solid-state memory.

[0120] In certain embodiments, memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory 302 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the displayed methods in the above embodiments according to this application.

[0121] The processor 301 implements any of the display methods described in the above embodiments by reading and executing computer program instructions stored in the memory 302.

[0122] In one example, the electronic device may also include a communication interface 303 and a bus 310. For example, Figure 12 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0123] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0124] Bus 310 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0125] The electronic device can execute the display method in the embodiments of this application, thereby achieving a combination Figures 1 to 11 The described display method and apparatus.

[0126] Furthermore, in conjunction with the display methods described in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the display methods described in the above embodiments. Examples of computer-readable storage media include non-transitory computer-readable storage media, such as portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, etc.

[0127] Furthermore, in conjunction with the display methods described in the above embodiments, this application embodiment can provide a computer program product for implementation. This program product is stored in a storage medium and may specifically include a computer program or instructions. When executed by a processor, the computer program or instructions implement any of the display methods described in the above embodiments. This program product is executed by at least one processor to implement the various processes of the above display method embodiments and achieves the same technical effects; therefore, to avoid repetition, further details are omitted here.

[0128] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0129] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0130] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0131] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer 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 these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0132] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A display method, characterized in that, This is applied to display devices, where a container is created within the HarmonyOS operating system of the display device. The container encapsulates the runtime environment of the Linux operating system and deploys applications, including: Obtain the display data stream output by the container, the display data stream including the application identifier of the application and window data corresponding to each of the at least two functional windows generated by the application; Based on the application identifier, at least two extended function components associated with the application identifier are determined from a preset set of extended function components, and one extended function component is configured to process window data corresponding to a function window; Display at least two display windows based on the at least two extended functional components; Among them, the first display window in the at least two display windows displays the window screen output by the first extended function component in the at least two extended function components after rendering the window data corresponding to the first function window in the at least two function windows; The second display window in the at least two display windows displays the window screen output by the second extended function component in the at least two extended function components after rendering the window data corresponding to the second function window in the at least two function windows.

2. The method according to claim 1, characterized in that, The step of displaying at least two display windows based on the at least two extended functional components includes: Based on the at least two extended functional components, obtain the native window object associated with each extended functional component; Through each of the extended functional components, render the window data corresponding to the functional window processed by each extended functional component to obtain rendering data corresponding to each window data; The rendering data corresponding to the function window processed by each extended function component is input into the native window object associated with each extended function component, and the at least two display windows are displayed through the native window object associated with each extended function component.

3. The method according to claim 1 or 2, characterized in that, Before determining at least two extended functional components associated with the application identifier from a preset set of extended functional components based on the application identifier, the method further includes: Obtain the application window configuration information output by the container. The application window configuration information includes the application identifier of the application, and the window identifier and window attribute information of each of the at least two functional windows supported by the application. The application window configuration information is output by the container when the application is installed. Based on the window attribute information of each functional window, create an extended functional component corresponding to each functional window; Establish and store the application identifier, the window identifier of each functional window, and the association relationship between the extended functional components corresponding to each functional window to obtain the preset extended functional component set.

4. The method according to claim 3, characterized in that, After creating the extended functional component corresponding to each functional window based on the window attribute information of each functional window, the method further includes: Based on the window attribute information of each functional window, determine the display surface of each functional window; Create a native window object associated with each functional window based on the display surface of each functional window.

5. The method according to claim 1, characterized in that, The first remote desktop service component is deployed in the HarmonyOS operating system's runtime environment, and the second remote desktop service component is deployed in the container; The method further includes: Receive the user's first input, which is the input to start the application; In response to the first input, the application startup information corresponding to the first input is input to the second remote desktop service component through the first remote desktop service component, and the second remote desktop service component is configured to launch the application according to the application startup information; When the application is launched, the display data stream output by the container is acquired.

6. The method according to claim 1 or 5, characterized in that, The first remote desktop service component is deployed in the HarmonyOS operating system runtime environment, and the second remote desktop service component is deployed in the container; obtaining the display data stream output by the container includes: Receive a second input from the user, the second input being an input to the target display window in the at least two display windows; In response to the second input, the first remote desktop service component inputs the display screen update information corresponding to the second input into the second remote desktop service component; the second remote desktop service component is configured to update the window data of the function window corresponding to the target display window according to the display screen update information; The first remote desktop service component obtains the display data stream output by the container based on the updated window data of the functional window corresponding to the target display window.

7. The method according to claim 1 or 5, characterized in that, The method further includes: deploying a first remote desktop service component in the HarmonyOS operating system runtime environment, deploying a second remote desktop service component in the container, and deploying a window composition component in the container; the method also includes: Receive a third input from the user, wherein the third input is an input to adjust the display resolution of the target display window in the at least two display windows; In response to the third input, the first remote desktop service component inputs the display resolution adjustment information corresponding to the third input to the second remote desktop service component. The second remote desktop service component is configured to input the display resolution adjustment information to the window composition component. The window composition component is configured to adjust the display resolution of the target function window corresponding to the target display window according to the display resolution adjustment information. The adjusted window attribute information output by the second remote desktop service component is obtained through the first remote desktop service component, and the adjusted window attribute information is determined based on the adjusted display resolution of the target function window. The display resolution of the display window corresponding to the target function window is adjusted using the adjusted window attribute information.

8. A display device, characterized in that, An application for a display device, wherein a container is created within the HarmonyOS operating system of the display device, the container encapsulates the runtime environment of the Linux operating system, and the container deploys applications; the device includes: The first acquisition module is used to acquire the display data stream output by the container, the display data stream including the application identifier of the application and the window data corresponding to each of the at least two functional windows generated by the application; The first determining module is used to determine at least two extended functional components associated with the application identifier from a preset set of extended functional components, based on the application identifier. One extended functional component is configured to process window data corresponding to a functional window. The display module is configured to display at least two display windows based on the at least two extended functional components; Among them, the first display window in the at least two display windows displays the window screen output by the first extended function component in the at least two extended function components after rendering the window data corresponding to the first function window in the at least two function windows; The second display window in the at least two display windows displays the window screen output by the second extended function component in the at least two extended function components after rendering the window data corresponding to the second function window in the at least two function windows.

9. An electronic device, characterized in that, The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the display method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device is able to perform the display method as described in any one of claims 1-7.

Images