丽台显卡p1000渲染好吗

本文探讨了丽台显卡p1000在渲染方面的表现，针对其性能进行分析。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

丽台显卡p1000渲染好吗

There are many performance tools built-in Chromium out of the box, that could help you find and debug performance issues in your app. The key to success is using the right tool for the task, exactly like bringing the right gun for a fight.

开箱即用的Chromium内置了许多性能工具，可以帮助您查找和调试应用中的性能问题。成功的关键是使用正确的工具完成任务，就像带上正确的武器进行战斗一样。

When facing a performance issue in your app, the first thing to do is to determine which category to focus on. This will help you to decide which tools to use. In general, there are three main performance categories:

遇到应用程序中的性能问题时，首先要做的就是确定要关注的类别。这将帮助您决定使用哪些工具。通常，主要有三个性能类别：

Load: It takes too long since the app opens until content is loaded and intractable.
加载：自从应用打开后，直到内容加载且难以处理为止，它花费的时间太长。
Logic: It takes too long to respond to user actions, or an ongoing background task is slowing the app.
逻辑：响应用户的动作时间太长，或者正在进行的后台任务正在拖慢应用程序的速度。
Rendering: UI elements and animations seem sluggish and unresponsive.
渲染：UI元素和动画似乎呆滞且无响应。

In this article, we’ll focus on rendering issues, how to identify them, what tools to use, and a few tricks and tips to help you get started.

在本文中，我们将重点介绍渲染问题，如何识别问题，使用哪些工具以及一些技巧和提示以帮助您入门。

您的应用程序是否存在渲染问题？ (Does your app have rendering issues?)

Detecting whether your app has rendering issues is done by exploring the app features. If you experience one of the following, then you probably have some rendering issues:

通过探索应用程序功能来检测您的应用程序是否存在渲染问题。如果遇到以下情况之一，则可能存在一些渲染问题：

Mouse hover animations are slow and sluggish
鼠标悬停动画缓慢且缓慢
Transition animations are slow and sluggish
过渡动画缓慢而缓慢
Switching between different views, like windows or menus, takes too much time and seems bumpy
在不同的视图(例如窗口或菜单)之间进行切换会花费太多时间，并且看起来比较坎bump
UI elements are not responsive
UI元素无响应

Most of these issues are caused due to improper layout and CSS usage that results in unneeded paints. For example, when we hover a button and get the hover effect, we obviously must paint that button again. But if we needlessly paint other areas in the UI, as a result of the button hover, we are wasting system resources.

这些问题中的大多数是由于布局和CSS使用不当而导致的，不需要油漆。例如，当我们将按钮悬停并获得悬停效果时，显然我们必须再次绘制该按钮。但是，如果由于鼠标悬停而不必要地在UI中绘制其他区域，则会浪费系统资源。

When too many things paint and repaint, every time — we start to see noticeable performance degradation.

当太多的东西需要绘画和重绘时，每次-我们开始看到明显的性能下降。

工具类 (Tools)

Fortunately for us, chrome has great tools to help us detect and solve rendering problems. Open Chrome DevTools, click on the three dots menu, “More tools”, and “Rendering”.

对我们来说幸运的是，chrome具有出色的工具来帮助我们检测和解决渲染问题。打开Chrome DevTools，单击三个点菜单，“更多工具”和“渲染”。

This will open the Rendering tab

这将打开“渲染”选项卡

在此处阅读有关“渲染”标签的更多信息： https : //developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#rendering

Paint flashing

油漆闪烁

The main tool for painting issues is Paint flashing. It’s very straight forward, enables this option and you’ll see on top of your UI green rectangles indicating that the area has been repainted.

绘画问题的主要工具是“ 绘画闪烁”。 非常简单，启用此选项，您将在UI顶部看到绿色矩形，指示该区域已重新粉刷。

For example, below is Outplayed. When hovering over the video player, we show the player controls overlay.

例如，下面是Outplayed 。将鼠标悬停在视频播放器上时，我们会显示播放器控件的叠加层。

So we expect the rectangle of the entire video player to be repainted. But with Paint flashing enabled, hovering the player will show us this:

因此，我们希望重新绘制整个视频播放器的矩形。但是在启用“ Paint”闪烁的情况下 ，悬停播放器将向我们显示以下内容：

Well, that’s not good. Hovering the video player results in the repainting of many unrelated areas. Clearly we had an issue that needed to be fixed. Using some of the tricks presented below, we were able to fix the issue, and get the expected result:

好吧，那不是很好。悬停视频播放器会导致许多不相关区域的重新粉刷。显然，我们有一个问题需要解决。使用下面介绍的一些技巧，我们能够解决问题，并获得预期的结果：

That’s more like it. And now, we continue to test our app, with the Paint flashing enabled, searching for all the cases we get unexpected green areas.

这还差不多。现在，我们在启用“ 涂漆”闪烁的情况下继续测试我们的应用程序，搜索所有遇到意外绿色区域的情况。

在此处详细了解绘画区域： https ： //developers.google.com/web/fundamentals/performance/rendering/simplify-paint-complexity-and-reduce-paint-areas

Scrolling performance issues

滚动性能问题

We use scrolling whenever we want to offer more content than what fits the screen, but scroll will actually result in painting the entire scrolled area again, and again. That does not mean we should not use scrolls, but we do need to pay attention to scroll areas.

每当我们想要提供比屏幕显示更多的内容时，我们都会使用滚动，但是滚动实际上会导致一次又一次地绘制整个滚动区域。这并不意味着我们不应该使用滚动条，但是我们确实需要注意滚动条区域。

Enabling the Scrolling performance issues flag will mark on the app UI the areas that are going to be repainted when the user scrolls. It will also show any registration to scroll events, that helps us verify that things are as expected.

启用“ 滚动性能问题”标记将在应用程序UI上标记用户滚动时将要重新绘制的区域。它还将显示滚动事件的所有注册，这有助于我们验证事情是否如预期。

For example, in Outplayed, we would expect to see 2 scroll areas. One at the matches navigation at the top, and one at the timeline at the bottom.

例如，在“已播放”中，我们希望看到2个滚动区域。一个在比赛导航顶部，一个在时间轴底部。

Enabling the Scrolling performance issues flag had a surprising result:

启用“ 滚动性能问题”标志的结果令人惊讶：

So aside from being a good verification that everything is working as expected, we actually can find unexpected behaviors. Why do we have a mouse wheel event listener registered to the window? After fixing the issue, the areas are marked as expected:

因此，除了可以很好地验证一切都按预期进行之外，我们实际上还可以发现意外的行为。为什么我们在窗口上注册了鼠标滚轮事件监听器？解决问题后，将这些区域标记为预期的：

A reference for this flag can be found here: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#scrolling-performance-issues

可以在以下位置找到此标志的参考： https : //developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#scrolling-performance-issues

More tools

更多工具

While we found the above tool to be the most useful when trying to improve render performance issues, the Rendering tab has many other tools to offer. You can read more about each of them here: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#rendering

尽管我们发现上述工具在尝试改善渲染性能问题时最有用，但“ 渲染”选项卡还提供了许多其他工具。您可以在这里阅读有关它们的更多信息： https : //developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#rendering

技巧和窍门 (Tips and Tricks)

So we were able to dramatically improve the rendering performance for Outplayed using the above tools. Here is a list of the things we ended up doing:

因此，使用上述工具，我们能够大大提高Outplay的渲染性能。这是我们最终要做的事情的列表：

Use CSS “contain” whenever possible — The easiest way to remove those unrelated repaint areas, is to use the CSS property contain. This property allows you to indicate that an element, and it’s content, are independent and will not affect other areas. This will result in amazing performance benefits.
尽可能使用CSS“包含” —删除那些无关的重绘区域的最简单方法是使用CSS属性contains 。此属性使您可以指示元素及其内容是独立的，不会影响其他区域。这将带来惊人的性能优势。
Avoid backdrop-filter — Although it’s supported, backdrop-filter has terrible performance and a huge negative impact on the overall performance of the rendering pipeline. If you must have filters, try to use regular filters when possible, and restrict backdrop-filter to small areas.
避免使用背景过滤器 -尽管受支持，但背景过滤器的性能很差，并且对渲染管道的整体性能产生巨大的负面影响。如果必须使用滤镜，请尝试尽可能使用常规滤镜，并将背景滤镜限制在较小的区域。
Reduce the use of z-index — Instead, try to place the elements in their respective locations in the DOM.
减少使用z-index-而是尝试将元素放置在DOM中的相应位置。
Remove unnecessary use of background-attachment: fix — From our experiments, background-attachment: fix has a negative impact on performance, and when possible it’s better to avoid it.
删除不必要的背景附件：修复方法 -从我们的实验中，背景附件：修复方法会对性能产生负面影响，最好避免这种情况。
Handle mouse wheel event listener better — When registering an event listener, you can add extra parameters that may improve the overall performance. For example, adding the passive flag, helped us to fix the issue we had with the mouse wheel.
更好地处理鼠标滚轮事件侦听器 —注册事件侦听器时，可以添加额外的参数，这些参数可以改善整体性能。例如，添加被动标志可以帮助我们解决鼠标滚轮问题。
Remove use of mix-bland-mode — Although might be useful sometimes, mix-bland-mode will have a negative impact on performance.
取消使用混合平淡模式 -尽管有时可能有用，但是混合平淡模式将对性能产生负面影响。
Reduce selectors complexity — Using nested selectors will trigger unneeded recalculations. For example, when writing “#menu > .items > li > h1”. Modifying things inside “#menu” will trigger recalculations for it, but also for “.items”, “li”, and “h1” elements in that node. To avoid that, use a single css selector, like “.menu-title”.
降低选择器的复杂性 -使用嵌套选择器将触发不必要的重新计算。例如，编写“ #menu> .items> li> h1”时。修改“ #menu”中的内容将触发该操作的重新计算，还会触发该节点中“ .items”，“ li”和“ h1”元素的重新计算。为了避免这种情况，请使用单个CSS选择器，例如“ .menu-title”。
Use css grid as base layout — Creating the base layout using css grid technique allows you to place components inside grid cells and isolate them more easily.
使用CSS网格为基础的布局 -通过创建基地布局CSS电网技术可以让您网格单元内的地方组件，更容易隔离。