A method for switching the rendering backend of the kwin window manager

Abstract

The present invention relates to the technical field of window special effects, and specifically provides a switching method for a kwin window manager rendering backend, including detecting a graphics card model according to preset parameters when the kwin window manager is started, judging whether the current graphics card is a low-performance graphics card; traversing all special effects of the kwin window manager, disabling all advanced special effects for low-performance graphics cards, only enabling the forbidden content movement special effect, and enabling corresponding special effects for non-low-performance graphics cards according to presets; in enabling the forbidden content movement special effect, monitoring window drag events, when the window is moving, updating the dragging window coordinate currentGeometry in a callback function, and drawing a moving rectangular outer frame according to the window coordinate currentGeometry, and triggering full-screen redrawing when the window is moved. The technical problem of the low-performance graphics card window dragging special effect freezes is solved.

Description

Technical Field

[0001] The present invention relates to the technical field of window special effects, and specifically provides a method for switching a kwin window manager rendering backend. Background Art

[0002] The wave of localization has been set off, and various products such as domestic operating systems, domestic databases, and domestic graphics cards have emerged. In the actual deployment of domestic operating systems, there are some adaptation problems between different domestic graphics cards. In the field of window rendering, there are performance differences between independent graphics cards and integrated graphics cards for domestic graphics cards such as Moore Thread, Core Pupil, Core Motion, GP201, Jingjiawei, Feiteng Integrated Graphics, and Loongson Integrated Graphics. There are also performance differences between independent graphics cards of different series of graphics cards. How domestic operating systems can make special adaptations to the capabilities of different graphics cards to ensure the user's final graphics operation is a problem that often needs to be faced in the adaptation of the whole machine. In many cases, for low-performance graphics cards, software rendering will be considered, and all special effects will be turned off. However, for some graphics cards with extremely low performance, the most basic window dragging will cause the graphics operation to freeze and dragging to be unsmooth.

[0003] Window special effects are all implemented by the compositor. The rendering backend of the 3D compositor is OpenGL, and 3D rendering is achieved through the GPU. When the graphics card is not powerful enough and its 3D acceleration function cannot be used, we will choose a 2D compositor, whose rendering backend is XRender. 2D rendering is usually achieved through CPU calculations, but the actual implementation depends on the support of the X server and the graphics hardware driver. If supported, the 2D graphics engine of the graphics card can be used to perform 2D hardware acceleration of two-dimensional graphics. If the graphics card does not even support 2D hardware acceleration, 2D rendering can only be performed through the CPU. 2D rendering usually has low requirements for computing resources and can produce high-quality output on weaker hardware.

[0004] Under the premise that it has been determined that the graphics card performance is relatively poor and 2D rendering is enabled in the window rendering backend, some low-performance graphics cards will still experience graphics operation jams when dragging the window, and the window cannot smoothly follow the mouse drag to move to a new position, which greatly affects the user experience.

[0005] Patent application number CN202011160368.6 discloses a method for controlling window display effects. In an already running system desktop environment, it provides a display effect switching function, and before the user requests a switch, it first determines whether the current computing device can support the window switching display effect, including transparent effects, minimized animation effects, etc. The function of switching window display effects will be provided to the user only when the actual hardware configuration of the computing device and the current load and operating capacity can support the window switching display effect. This patent mainly controls the application of window special effects, and automatically turns off some special effects for low-performance graphics cards, but does not propose a new special effect implementation solution to adapt to low-performance graphics cards. Summary of the invention

[0006] In order to overcome the above defects, the present invention proposes a method for realizing window dragging special effects for domestic low-performance graphics cards, so as to solve the technical problem of the lag of window dragging special effects on low-performance graphics cards.

[0007] The present invention provides a method for switching a window synthesizer rendering backend, comprising the steps of:

[0008] When the kwin window manager is started, the graphics card model is detected according to the preset parameters to determine whether the current graphics card is a low-performance graphics card;

[0009] Traverse all the special effects of the kwin window manager, disable all advanced special effects for low-performance graphics cards, and only enable the special effect of prohibiting content movement. For non-low-performance graphics cards, enable the corresponding special effects according to the preset;

[0010] When enabling the forbidden content moving special effect, listen to the window dragging event. When the window is moving, update the dragging window coordinates currentGeometry in the callback function, and draw the moving rectangular frame according to the window coordinates currentGeometry. When the window moves, trigger full-screen redrawing.

[0011] Furthermore, the advanced special effects include but are not limited to blur effects, cube and its sliding effects, disintegration effects, switch flip effects, zoom effects and rounded corner effects.

[0012] Further, drawing the moving rectangular frame according to the window coordinate currentGeometry includes:

[0013] Draw the upper and lower borders, and determine their positions according to the window coordinates. Both the upper and lower borders are small rectangular boxes with sizes of x, y, width, and n. Among them, x and y represent the current window coordinates, width represents the current window width, and n represents the border width;

[0014] Draw left and right borders, and determine their positions according to the window coordinates. Both left and right borders are small rectangular frames with a size of x, y, n, height - 2. Among them, x, y represent the current window coordinates, n represents the border width, and height represents the height of the current window.

[0015] further,

[0016] The function prePaintScreen of the pre-drawing stage of the prohibition of content movement effects adds PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS to the drawing mask, indicating that there is at least one window on the screen with a transformed geometry;

[0017] The function prePaintWindow of the pre-drawing stage for prohibiting the content movement special effect adds PAINT_WINDOW_TRANSFORMED to the drawing mask, indicating the coordinate change when a single window is drawn.

[0018] Working principle and beneficial effects of the present invention:

[0019] In the technical solution of the present invention, when dragging a window, the synthesizer skips the visible area of ​​the window when rendering each frame, and only renders the rectangular frame data of the outermost border of the window when it moves, thereby avoiding the copying of all pixels in the entire window, improving rendering performance and optimizing the user's interactive experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The disclosure of the present invention will become more easily understood with reference to the accompanying drawings. It is easy for those skilled in the art to understand that these drawings are only for illustrative purposes and are not intended to limit the scope of protection of the present invention. In addition, similar numbers in the figures are used to represent similar components, among which:

[0021] Figure 1 It is a schematic flow chart of the main steps of a method for switching a window synthesizer rendering backend according to the present invention;

[0022] Figure 2 It is a schematic diagram of the class diagram relationship of the kwin special effect chain call of the present invention;

[0023] Figure 3 It is a schematic diagram of window movement using the special effect of prohibiting content movement in the present invention. DETAILED DESCRIPTION

[0024] Some embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the protection scope of the present invention.

[0025] The present invention mainly constructs a new special effect implementation, namely, the special effect NoContentMove, which prohibits content movement, and then directly applies the special effect implementation to the window manager of the current KDE desktop series, such as ukui-kwin of Kylin Desktop, deepin-kwin of Tongxin Desktop, or community version of kwin. When dragging a window, the 2D synthesizer skips the content visible area of ​​the window for each frame rendering, and only renders the rectangular frame data of the outermost border of the window, thereby avoiding the copying of all pixels in the entire window, improving rendering performance, and optimizing the user's interactive experience.

[0026] Figure 1 FIG. 1 is a flow chart of the main steps of a method for switching a window synthesizer rendering backend according to the present invention. Figure 1 As shown, a method for switching a window compositor rendering backend in this embodiment mainly includes the following steps S10 to S30.

[0027] Step S10: When the kwin window manager is started, the graphics card model is detected according to the preset parameters to determine whether the current graphics card is a low-performance graphics card. Specifically, the corresponding low-performance graphics card is matched according to the actual project adaptation situation, such as setting the preset parameters to 2K500.

[0028] In one implementation, if the current graphics card is determined to be a low-performance graphics card, a flag lowvgapci is recorded to indicate the low-performance graphics card state. In step 20, the low-performance graphics card is detected according to the flag.

[0029] Step S20: traverse all special effects of the kwin window manager, disable all other advanced special effects for low-performance graphics cards, and only enable the prohibition of content movement special effect (NoContentMove); for non-low-performance graphics cards, enable corresponding special effects according to the preset, specifically, enable all advanced special effects.

[0030] In one implementation, when the low-performance graphics card only enables the NoContentMove effect, only the NoContentMove effect is set

[0031] LoadEffectFlag: Load, other special effects do not have this flag. This flag is used to determine whether the special effect is loaded.

[0032] Figure 2 This is a schematic diagram of the class diagram relationship of the kwin special effect chain call of the present invention. Figure 2 As shown in the figure, the entire class framework relationship is native to the KDE window management system, which is a relatively clear concept. When the kwin window manager is started, all special effects will be loaded into m_activeEffects. The specific process is:

[0033] First, the built-in special effects information supported by the kwin window manager is stored in a QVector container named s_effectData. Then, the kwin window manager traverses all members in the container s_effectData (i.e., all supported special effects), parses each special effect information and saves it. The availableEffects function can be used to obtain a list of all built-in special effects, indicating the currently available special effects. In order to load special effects in an orderly manner, the window manager will obtain a list of all special effects through the availableEffects function, and control the loading process of special effects through a queue. Only special effects marked as LoadEffectFlag::Load will be actually loaded and saved to m_activeEffects. In step S20, only NoContentMove sets this flag. In other words, in the scenario of this patent, after a low-performance graphics card is detected, all other advanced special effects are disabled, and m_activeEffects actually has only one nocontentmove.

[0034] The so-called special effect chain call of the kwin window manager refers to traversing m_activeEffects and calling the interface function of each effect (special effect implementation) one by one. For example, the linked list in this patent actually has only one member, which is the paintScreen function implemented by nocontentmove itself. After the linked list ends, the final rendering action is executed to apply the drawing effect to the rendering channel. PaintScreen is a function name used to draw elements on the screen.

[0035] In this embodiment, the special effects developed for low-performance graphics cards are Figure 2 The green NoContentMove, when the kwin window manager detects a low-performance graphics card at startup, automatically updates the loading flags of all special effects (that is, all the special effects that can be obtained by availableEffects above, and sets them one by one whether LoadEffectFlag::Load), only enables NoContentMove, and all other special effects are marked as disabled. This makes the rendering channel have only one adaptation special effect NoContentMove for low-performance graphics cards, so that when dragging windows, the purpose of reducing resource usage and improving performance is achieved.

[0036] In one embodiment, all special effects of the kwin window manager include various advanced window special effects native to the prior art, as well as the newly proposed content movement prohibition special effect (NoContentMove) adapted to low-performance graphics cards in this embodiment. Among them, advanced window special effects include but are not limited to blur effects (Blur and BlurInactive), cubes and their sliding effects (Cube and CubeSlide), disintegration effects (FallApart), switch flip effects (FlipSwitch), zoom effects (Zoom), rounded corner effects (UBR), etc. In the scenario involved in this embodiment, once a low-performance graphics card is detected, all other advanced special effects are disabled and only the NoContentMove special effect is enabled.

[0037] Step S30: When the special effect NoContentMove is enabled, the window dragging event is monitored. When the window is moving, the coordinates of the dragged window currentGeometry are updated in the callback function, and the moving rectangular frame is drawn according to the coordinates. When the window moves, the full screen is redrawn. It should be noted that in the preparation function prePaintWindow for each frame drawing, the drawing mask of the window is set.

[0038] PAINT_WINDOW_TRANSFORMED, with this flag, the canvas will skip the window content when drawing the entire desktop, leaving it to the special effect to implement the drawing method. In actual drawing, the frequency is relatively high, which can be understood as drawing nearly 60 frames per second.

[0039] When the window is moving, the window coordinates currentGeometry are updated in the callback function of the window drag event. The paintWindow function, which is called when drawing each frame, draws the moving rectangular frame according to the coordinates currentGeometry. When the window is dragged, the changing area on the screen when the 2D synthesizer synthesizes the final image is a thin border, assuming the border width is 1px.

[0040] Draw the upper and lower borders: relative to the window position, the sizes of these two small rectangular boxes are: 0,0,width,1. Among them, 0,0 represents the current window coordinates, width represents the width of the current window, and 1 represents the border width;

[0041] Draw the left and right borders: relative to the window position, the sizes of these two small rectangular boxes are: 0,0,1,height-2. 0,0 represents the current window coordinates, 1 represents the border width, and height represents the current window height. The reason for subtracting 2 is that the upper and lower borders use up two pixels.

[0042] Furthermore, for each frame of drawing, the paintScreen function of the canvas Scene will be executed. Generally speaking, the drawing process of each special effect includes three stages: pre-drawing stage pre paint, drawing stage paint and post-drawing stage post paint. Among them, the post-drawing stage (post paint) can be used for cleaning and arranging redrawing in the next drawing process to support animation special effects. The nocontentmove special effect in this embodiment only requires the drawing process of the first two stages. The processing of drawing data is realized by calling each prePaintScreen, prePaintWindow, paintScreen, paintWindow, postPaintWindow, postPaintScreen and other interfaces of each special effect to implement effects. Each special effect can implement these functions of its own, but it is not required to implement all of them. The nocontentmove of this patent only needs to implement its own prePaintScreen, prePaintWindow and paintWindow.

[0043] The pre-paint stage is used to determine the actual drawing process, that is, how the special effect will be executed. The drawing method is controlled by the mask parameter. In the nocontentmove special effect, the pre-paint stage sets the mask to: PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS and PAINT_WINDOW_TRANSFORMED. When dragging a window, the drawing of the dragged window in each frame is realized by the special effect, so that only the rectangular box outside the window coordinates is updated.

[0044] In one implementation, the pre-painting phase function prePaintScreen of the nocontentmove effect adds PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS to the drawing mask, indicating the transformed geometry of at least one window on the screen. Simply put, when a window is dragged from one position to another, its coordinate position changes.

[0045] In one implementation, the pre-painting phase of the nocontentmove effect, prePaintWindow, adds PAINT_WINDOW_TRANSFORMED to the drawing mask to indicate the coordinate change when drawing a single window. If this flag is present, the area content when drawing the window is determined by the effect. If this flag is not present, the content of the drawn window is the entire visible area of ​​the window, that is, the actual content of the window. Therefore, this flag is very important for our special effects.

[0046] The paint phase performs the actual painting work based on the information collected in the pre-paint phase.

[0047] The entry function of the 2D compositor to draw each frame is performCompositing. After the lowvgapci low-performance flag is obtained through the previous graphics card recognition, the function goes to the paintScreen of the XRender backend and then returns to the paintScreen of the canvas [the original rendering path, this patent is embedded in this path].

[0048] Specifically, the paintScreen of the canvas Scene 1 Set the prePaintScreen and paintScreen corresponding to the different special effects in m_activeEffects 2 (paintScreen here 2 Indicates the operation of each special effect, the paintScreen in the previous article 1 Indicates that canvas Scene operations) and postPaintScreen are all executed.

[0049] The execution order of the functions implemented by the canvas paintScreen function special effects in the rendering path is:

[0050] First, chain effects->prePaintScreen to collect mask [including the implementation of nocontentmove];

[0051] Next, chain effects->paintScreen, wait for the special effect paintScreen to complete, traverse all windows and chain effects->prePaintWindow [including the implementation of nocontentmove] and effects->paintWindow [including the implementation of nocontentmove]. Among them, effects->prePaintWindow collects the mask of window drawing, and effects->paintWindow performs the drawing operation.

[0052] Traverse all windows and chain effects->postPaintWindow

[0053] Finally, chain effects->postPaintScreen.

[0054] The pre-drawing stage of the rendering path is mainly used to collect rendering masks, and the post-drawing stage is mainly used for advanced special effects animation effects that are not covered by this patent. In this embodiment, there is only one nocontentmove special effect, and only implements its own prePaintScreen, prePaintWindow and paintWindow functions. Therefore, the paintScreen of the canvas Scene 1 The most critical drawing in this part of the special effects chain is the special effects paintWindow function.

[0055] The paintWindow() function of the canvas Scene will traverse the paintWindow() methods of all special effects until the last finalPaintWindow() is called.

[0056] finalPaintWindow is the drawWindow() of the chained special effect. This special effect does not implement its own drawWindow, so it is hung on the original rendering path and goes to the finalDrawWindow of the canvas Scene. This finalDrawWindow method calls the performPaint() method of the window to perform the actual drawing.

[0057] In the implementation of this patent, the performPaint of the window refers to the implementation function of the XRender backend: SceneXrender::Window::performPaint(int mask, QRegion region, WindowPaintDatadata), which calculates the area of ​​the drawing window according to the mask set in the pre-drawing stage. When it is recognized that as mentioned above, the rendering path actually draws the special effect paintWindow during the window dragging process, that is, only the border is drawn. The window content is passed

[0058] PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS and PAINT_WINDOW_TRANSFORMED masks are suppressed and no longer drawn completely following the mouse. What is drawn is only the four border data collected by paintWindow in nocontentmove.

[0059] The nocontentmove effect calculates the area of ​​the rendering data when dragging and sends it to the display (upper, lower, left and right borders), and then calls the performPaint function of the XRender backend to determine the final content rendered on the screen according to the set mask PAINT_WINDOW_TRANSFORMED. In the pre-drawing stage, the prePaintWindow function of the nocontentmove effect sets the mask, and finally the performPaint of the XRender backend will draw with the XCB_RENDER_PICT_OP_OVER rendering operation. Therefore, the newly drawn content, that is, the border, will eventually be rendered to the final image and displayed on the screen for us to see.

[0060] In a specific implementation, the three drawing functions implemented by the nocontentmove special effect overload these functions of the special effect to mount themselves on the rendering path of the kwin window manager.

[0061] Function: NoContentMoveEffect::prePaintScreen(ScreenPrePaint Data&data, intpresentTime) sets the mask PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS

[0062] Function: NoContentMoveEffect::prePaintWindow(EffectWindow*w,WindowPrePaintData&data,int presentTime) sets the mask PAINT_WINDOW_TRANSFORMED

[0063] Function: NoContentMoveEffect::paintWindow(EffectWindow*w,int mask,QRegionregion,WindowPaintData&data) This function calculates the four borders of the dragging window coordinate position.

[0064] When you select the title bar of a window with the mouse, press and drag, the window will move in real time with the mouse position. Assuming the window size is 600x300, there will be 180,000 pixels copied. This content copying is also a heavy burden on low-performance graphics cards. Figure 3 is a schematic diagram of window movement using a special effect of prohibiting content movement in the present invention, such as Figure 3As shown, the NoContentMove special effect in this embodiment is that when the user selects a window to drag, the synthesizer only draws four small rectangular boxes corresponding to the position of the moving window coordinates when rendering the screen image, and merges them into a rectangular outer frame. When the user releases the mouse, the drag event is completed, triggering a full-screen redraw, and copying all the window contents.

[0065] In solving the problem of the special effects of dragging windows on low-performance graphics cards being stuck, there are currently similar implementations in which only the border follows the mouse movement when dragging a window, and such implementations are generally in the marco window manager. A reduce-resources switch is provided. After turning on this switch, resources will be saved when dragging the window, and the entire window will no longer be dragged, but it cannot be automatically adapted according to the graphics card performance. The present invention uses a method of prohibiting the content movement special effect to be implemented in the kwin window manager, and no manual operation is required by the user. When the graphics card performance is good, other advanced special effects of the kwin window manager are automatically enabled, such as rounded corners, frosted glass, shadows, etc. When the graphics card performance is poor, all other advanced special effects are disabled, and only the prohibition of content movement special effect (NoContentMove) is enabled, so that it can automatically adapt to the scenarios of high-end and low-end graphics cards without the need for manual operation by the user.

[0066] It should be pointed out that although the various steps in the above embodiments are described in a specific order, those skilled in the art can understand that in order to achieve the effects of the present invention, different steps do not have to be performed in such an order. They can be performed simultaneously (in parallel) or in other orders. These changes are within the scope of protection of the present invention.

[0067] Here are some terms involved in the present invention.

[0068] Window manager: System software used to control how application windows on the operating system desktop are displayed and how they interact. This includes window order, position, shape, etc. In modern desktop operating systems, window managers are an indispensable and important role. In the domestic Kirin desktop operating system, the window manager is ukui-kwin; in UOS, it is deepin-kwin; and in Zhongke Fangde, the window manager is mutter.

[0069] Window effects: Window effects refer to transparent windows, window shadow borders, animation effects of maximizing and minimizing windows, etc. The implementation principle of this type of effect is that all application window contents are first redirected to the off-screen cache, and the synthesizer takes the contents of the upper and lower overlay windows on the desktop and synthesizes them.

[0070] 3D compositor: 3D hardware acceleration support based on OpenGL, using hardware capabilities to synthesize window content, enhancing the system's 3D display performance. Due to the strong computing power of the GPU, this compositor supports more special effects.

[0071] 2D compositor: does not use the graphics card's hardware acceleration, but uses software for synthesis, and uses the XComposite plug-in to get the off-screen buffer and then synthesize, consuming CPU resources. Since the CPU has too many things to do and it is not a dedicated graphics computing unit, this type of compositor can only support some simple special effects.

[0072] Rendering path: paint pass, a concept in graphics, is also called rendering channel. In the context of KWin (KDE window management system), "paint pass" refers to a stage when the window manager handles window graphics rendering. It is the process of KWin performing actual drawing operations, including redrawing window contents, applying special effects, and interacting with graphics hardware to update the screen display, etc.

[0073] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

Claims

1. A method for switching a window synthesizer rendering backend, characterized in that: Includes steps: When the kwin window manager is started, the graphics card model is detected according to the preset parameters to determine whether the current graphics card is a low-performance graphics card; Traverse all the special effects of the kwin window manager, disable all advanced special effects for low-performance graphics cards, and only enable the special effect of prohibiting content movement. For non-low-performance graphics cards, enable the corresponding special effects according to the preset; When the special effect of prohibiting content movement is enabled, the window dragging event is listened. When the window is moving, the dragging window coordinate currentGeometry is updated in the callback function, and the moving rectangular frame is drawn according to the window coordinate currentGeometry. When the window movement is completed, full-screen redraw is triggered.

2. A method for switching a window synthesizer rendering backend according to claim 1, characterized in that: The advanced special effects include but are not limited to blur effects, cube and its sliding effects, disintegration effects, switch flip effects, zoom effects and rounded corner effects.

3. A method for switching a window synthesizer rendering backend according to claim 1, characterized in that: Drawing the moving rectangular frame according to the window coordinate currentGeometry includes: Draw the upper and lower borders, and determine their positions according to the window coordinates. Both the upper and lower borders are small rectangular boxes with sizes of x, y, width, and n. Among them, x and y represent the current window coordinates, width represents the current window width, and n represents the border width; Draw left and right borders, and determine their positions according to the window coordinates. Both left and right borders are small rectangular frames with a size of x, y, n, height - 2. Among them, x, y represent the current window coordinates, n represents the border width, and height represents the height of the current window.

4. The method for switching a window synthesizer rendering backend according to claim 1, characterized in that: The function prePaintScreen of the pre-drawing stage of the prohibition of content movement effects adds PAINT_SCREEN_WITH_TRANSFORMED_WINDOWS to the drawing mask, indicating that there is at least one window on the screen with a transformed geometry; The function prePaintWindow of the pre-drawing stage for prohibiting the content movement special effect adds PAINT_WINDOW_TRANSFORMED to the drawing mask, indicating the coordinate change when a single window is drawn.

Images