Qt 4/5和Opengl API之间的opengl速度差异 [英] Difference in opengl speed between Qt 4/5 and Opengl API

问题描述

我已经阅读所有的问题，我可以找到关于qt 4和5 opengl。这是最接近的 OpenGL和QOpenGL / QtOpenGL在Qt 5：差异和限制？，我不知道为什么它被关闭，因为它是一个伟大的问题。我唯一看不到的是速度差异。

我也阅读了这个 https：// qt-project。 org / forums / viewthread / 22921 有一个类似的问题，但作为来回约4对5，主要讨论新的功能。

我的问题是，是否使用QT5的内置方法比直接使用opengl API自定义窗口部件更快？如果我关注性能，使用QT是一个不好的选择，有

编辑：

一点更具体，我需要使用physx，tcp / ip通信，以及大量快速更新顶点和网格。目标是尽可能接近实时。像渲染这样的事情不是一个问题，但qt的任何开销都是有害的。 （一切都是用C ++的3D）

解决方案

我已经阅读所有的问题，可以找到关于qt 4和5 opengl。这是在Qt 5中最接近的OpenGL和QOpenGL / QtOpenGL：差异和限制？ ，我不知道为什么它被关闭，因为它是一个伟大的问题。我唯一看不到的是速度差异。

为了更具体一点，我需要使用physx，tcp / ip通信和大量快速更新顶点和网格。目标是尽可能接近实时。像渲染这样的事情不是一个问题，但qt的任何开销都是有害的。 （一切都是使用C ++的3D）

您的问题有多个问题。

RawOpenGL和QtOpenGL

这个问题是不对的，因为没有像Qt OpenGL这样的东西。 OpenGL是Khronos拥有并发布的标准。 Qt只是使用它。

Qt可以为你做什么帮助你的应用程序管理几个事情。

/上下文创建

你曾经尝试过在Win32下创建一个OpenGL上下文吗？它需要一堆锅炉代码（请参见此处或在这里），这涉及创建一个临时上下文以检查WGL功能，然后在最后创建实际上下文...

你曾经尝试过在X11下创建一个OpenGL上下文吗？它需要一堆锅炉代码（请参阅此处），其中涉及检查 GLX_ARB_create_context 存在，然后使用它创建上下文，或回退到GLX 1.3代码路径和...

您是否曾尝试在Mac OS X下创建OpenGL上下文？

您是否曾尝试过在Android下创建OpenGL上下文？

$ b $

您是否曾尝试过在DirectFB / EGLFS下创建OpenGL上下文？

哦，等等。这里来Qt：

  class Window：public QWindow {
 QOpenGLContext * context; 
 public：
 Window（）{
 QSurfaceFormat format; 
 format.setVersion（3,3）; 
 format.setProfile（QSurfaceFormat :: CoreProfile）; 
 
 setSurfaceType（OpenGLSurface）; 
 setFormat（format）; 
 create（）; 
 
 context = new QOpenGLContext; 
 context-> setFormat（format）; 
 context-> create（）; 
} 
 ... 
  

这创建了一个（顶层）OpenGL窗口和3.3核心配置文件上下文。结合它与QTimer和你有一个可行的渲染器。当然可以在所有上述平台上运行：Win32，Mac，X11，Linux / EGLFS，QNX，iOS，Android 。

---

b
$ b

有没有你需要支付的所有这一切的开销？当然是。但这绝对可以忽略不计;你只需要支付一次，即创建窗口和上下文时。

真正重要的东西来自于OpenGL绘图本身，完全在你的控制之下：您使窗口上的上下文当前并开始发布原始OpenGL命令。 Qt不是在那里的方式。只有当Qt和OpenGL再次相遇时才会在交换缓冲时间;

所以： Qt不会增加任何可测量的开销。

窗口管理

当然，与上面捆绑在一起的事实，你可以fi在任何平台上处理相同代码的键盘和鼠标输入。或调整窗口大小。或者使它全屏。或关闭它。

OpenGL帮助

Qt不是只是提供一种创建OpenGL表面和上下文和相关操作：设置为当前，交换缓冲区等）。它（进一步），提供了一系列辅助类和函数：

• QMatrix4x4 ... 4x4矩阵。它有一个OpenGL程序中需要的所有好的函数： lookAt（）， ortho（）， perspective（）， normalMatrix（），以此类推。


• QOpenGLContext :: hasExtension 和 QOpenGLContext :: getProcAddress 是解决OpenGL入口点的平台无关方式。


• QOpenGLContext :: versionFunctions 返回一个包含已解决的给定版本/配置文件的所有OpenGL入口点的对象。


• QOpenGLBuffer 包装一个缓冲区对象。


• QOpenGLVertexArrayObject 包装顶点数组对象（并具有RAII辅助函数，用于绑定和解除绑定VAO）。


• QOpenGLTexture <封装纹理对象。


• QOpenGLFrameBufferObject 包装一个框架缓冲对象。


• QOpenGLShader < QOpenGLShaderProgram 包装着色器和着色器程序，为fi提供了方便的方法将QMatrix4x4设置为统一变量。因此，您可以使用上述方法计算CPU上给定网格的MVP，然后将其设置为均匀。


• QOpenGLDebugLogger 包装 GL_KHR_debug 用于调试您的OpenGL应用程序。


• 还有一些我现在不记得的东西。






有开销吗？是的，但是它又是最小的，它不涉及如何在您的OpenGL代码 中使用这些对象。如果你的OpenGL代码快速，结构良好，你会发现这些帮助者有用的管理它，他们不会使它运行任何更慢。





_{（管理它的有用的例子：QOpenGLVertexArrayObject将允许您在OpenGL 3.0或任何桌面OpenGL版本上使用VAO，其中存在 GL_ARB_vertex_array_object 扩展， ES2如果 GL_OES_vertex_array_object 存在，你不需要根据运行时解决正确的函数集Qt会为你做，并提供相同的API用于创建，绑定，释放和销毁VAO）。}





一切都是好的吗？不，我必须诚实在这里，有位和螺栓，将受益于一些爱。





例如，QOpenGLFrameBufferObject有一个有限的API，不支持f.i.任何数量的颜色附件。 QOpenGLBuffer需要一些工作来支持更多的缓冲区类型/绑定目标。还没有对程序管道的支持。仍然不支持统一的缓冲区。





另一方面，你有一些东西，如QOpenGLTexture，它支持最近的功能，如不可变存储和纹理视图。





这是否意味着您无法使用这些功能？当然可以。只要回到原始的OpenGL代码，如果你需要功能Qt不给你现在。或者，请考虑将这些功能提供给Qt ！





Qt





当然，一旦你走的Qt路径，你有Qt。这意味着只在QtCore和QtGui库中：






• 事件循环


• timers


• 信号和插槽


• 线程


• Unicode字符串+ i18n




• 正则表达式


• 文件处理


• 插件加载


• 设置


• mimetypes


• 输入处理


• image I / O

<使用光栅引擎的
• 2D命令式绘画


• JSON


• XML








当然，上述所有都是跨平台的。





顺便说一句，Qt还有：






• 跨平台2d小部件的QtWidgets


• QtSql for DB access


• QtNetwork用于TCP / UDP / SSL套接字，以及高级HTTP / FTP引擎


• QtTest单元测试


• QtWebkit用于嵌入webkit


• 还有一些我现在不记得的东西






OpenGL在Qt 4 vs 5





在Qt 4中如何处理OpenGL有什么巨大的差异？不是真的...





在Qt 4中，用于做OpenGL渲染的类是QGLWidget。它住在QtOpenGL模块（而不是在QtGui - 记住在Qt 4窗口小部件居住在QtGui）。此外，实际上，上面列出的Qt 5 OpenGL帮助者的一个子集是在 QGLFoo 名称下（fi QGLBuffer 而不是 QOpenGLBuffer ）。





在Qt 5 QtOpenGL模块仍然存在，但是：







• QtGui和QtWidgets已拆分。 QtGui现在包含低级位处理WM，创建GL上下文和表面，2d绘画，基本上我上面列出的东西。




• QtOpenGL仍包含QGL *类，但现在链接到QtWidgets（因为它包含QGLWidget）。 这意味着使用QGLWidget意味着您将链接到某个大的库，即使您根本不使用窗口小部件（因为您的应用程序是纯OpenGL）。




• 如我之前所示，QtGui足以创建一个顶级的OpenGL窗口。但是如果你想将它嵌入基于小部件的应用程序呢？然后你仍然可以使用QGLWidget或通过 QWidget :: createWindowContainer 嵌入QWindow。 除了QGLWidget，你不应该使用任何其他QtOpenGL（即QGL）类。




• 所有上述QOpenGL *类都在QtGui，而不是在QtOpenGL ;它们比QGL *对应的更多（例如，没有QGLVertexArrayObject），它们有更多的特性（例如QOpenGLShader支持几何和镶嵌着色器，QGLShader不支持），以及一般使用的（因为他们会看到错误修正和改进，QGL *将不会）。




• 由于现在QtGui提供了OpenGL支持，所以期望QGLWidget替换直接出现在QtWidgets中是很自然的事。确实，它将，希望在5.4（准备工作进入5.3;但不幸的是，功能本身将错过功能冻结）。







---





有没有理由预期Qt 4和Qt 5之间有巨大的性能差异？不，我希望您的GL代码执行一模一样。





桌面GL / ES 2





您可以编译Qt 5通过配置时间开关支持桌面GL或ES 2。
显然会改变QtGui在编译时使用的标头，以及它将链接到的库（libGL或libGLES2等）。它还将更改默认表面格式：上述QWindow代码将创建一个很好的OpenGL ES2表面（并且可能会失败上下文创建，因为没有OpenGL ES 3.3，哦）。





但你得到的点：使用相同的代码，你也可以支持ES2。





问题（在我看来），它也会改变一些其他更微妙的东西：例如QOpenGLShader会插入一些宏如

  #define highp 
 #define mediump 
 #define lowp 
  p> 
 
 
在所有的着色器之前，如果你使用Desktop GL。原因是它允许您重新使用缺少精度限定符的ES2和Desktop GL 中的相同着色器;因此它们通过宏扩展到无。 
 
 
 
我认为这些小东西并不是真正的收获。也许他们减少维护非常小和简单的着色器（和程序只由一个顶点和碎片着色器）。 
 
 
 
但是，您的Google桌面GL代码路径可能使用更多的着色器阶段;或者通常使用ES2上不可用的功能。最终，它将显着偏离您的ES2代码路径。 （只要认为在3.3核心你必须使用VAO，而ES2自己不知道VAO是什么。）
 
 
 
 个人权限：我讨厌，讨厌，讨厌的事实，ES2不像一个OpenGL配置文件，而是坐在自己的。并且一个必须基本上有一个分歧的代码基地只是使ES2快乐。             strong>在Windows下也称为OpenGL驱动程序状态。
 
 
 
基本上，除了NVIDIA之外的任何人都在Windows上提供了破碎的OpenGL驱动程序。 
 
 
 
 至少，开箱即用。升级驱动程序通常有效，但是您并不总是要求用户升级他们的驱动程序。他们是最终用户，而不是亲玩家。也许他们甚至没有管理员权限。 
 
 
 
这是OpenGL应用程序的一个问题，特别是Qt的最强大的工具之一：Qt Quick 2。 Qt尝试使用ANGLE，它是一个OpenGL ES2  - > Direct3D翻译层解决这个问题。因此，在Windows下，您可以选择
 
 
 
 
 
桌面OpenGL版本
 
 
通过ANGLE构建
 
 
 
 
 
选择不相等 -  ES2当然意味着忘记做任何严重的现代GL。但除此之外，可以选择单向或其他方式的原因此处 a>。
 
 
 
 Qt Quick 2 
 
 
 
这很重要，我认为值得一提。 / p> 
 
 
但首先让我们澄清一下：你需要使用Qt Quick 2在Qt下构建一个OpenGL应用程序吗？  NO，NO和NO。 Qt Quick 2是一种完全独立的技术，它还利用OpenGL进行渲染。因此，你可以忽略它，只是构建你的OpenGL应用程序。
 
 
 
但是Qt Quick 2是什么？它是一个以 QML语言为基础的图书馆，它是一种声明性语言，主要用于创建动态UI（现在用于构建系统 ...哦好）。 
 
 
 
请记住以下区别：QML是语言，Qt Quick 2是一个包含一组可视化项目创建自己的），你在QML中编程。 
 
 
 
这是Qt Quick 2使用OpenGL来绘制这些视觉项目。这保证良好的60 FPS无泪的结果，非常低的CPU使用率，各种基于着色器的眼睛糖果等。
 
 
 
那么什么？嗯，你可能有兴趣给它一个踢。例如，API允许它被叠加到你绘制的任何纯OpenGL内容。所以你可以想到使用Qt Quick 2处理更传统的UI位 - 按钮，滑块等，同时控制主要内容的渲染。
 
 
 
或者，你可以忽略它存在的事实，并继续使用OpenGL。
 
I have read all the questions on SO that i could find about qt 4 and 5 opengl.  This one came the closest OpenGL vs QOpenGL/QtOpenGL in Qt 5: differences and limitations? , I have no idea why it was closed because its a great question.  The only aspect I see it missing is the speed difference.  

I have also read this https://qt-project.org/forums/viewthread/22921  which had a similar question, but as the back and forth about 4 vs 5, mostly discussing new features.  

My question is, is using the built in methods of QT5 faster than making a custom widget using the opengl API directly?  If I am concerned about performance, is using QT a bad choice and there 

EDIT:

To be a little more specific, I need to use physx, tcp/ip communication, and large numbers of quickly updating vertices and meshes.  The goal is to do this as close as realtime as possible.  Things like rendering is not a concern, but any bit of overhead from qt is damaging. (Everything is in 3D with C++)
解决方案

  
I have read all the questions on SO that i could find about qt 4 and 5 opengl. This one came the closest OpenGL vs QOpenGL/QtOpenGL in Qt 5: differences and limitations? , I have no idea why it was closed because its a great question. The only aspect I see it missing is the speed difference. 
  
  
To be a little more specific, I need to use physx, tcp/ip communication, and large numbers of quickly updating vertices and meshes. The goal is to do this as close as realtime as possible. Things like rendering is not a concern, but any bit of overhead from qt is damaging. (Everything is in 3D with C++)
There are multiple questions in your question.

"Raw" OpenGL vs "Qt" OpenGL

This question is ill posed, in that there's no such thing as "Qt OpenGL". OpenGL is the standard owned and published by Khronos. Qt just uses it.

What Qt can do for you is helping your application manage several things.

Window/context creation

Have you ever tried creating an OpenGL context under Win32? It requires a bunch of boilerplade code (see here or here), which involves creating a temporary context to check for WGL capabilities, then creating the actual context in the end...

Have you ever tried creating an OpenGL context under X11? It requires a bunch of boilerplade code (see here), which involves checking for GLX_ARB_create_context presence and then use it to create the context, or fall back to a GLX 1.3 code path and...

Have you ever tried creating an OpenGL context under Mac OS X?

Have you ever tried creating an OpenGL context under Android?

Have you ever tried creating an OpenGL context under QNX?

Have you ever tried creating an OpenGL context under DirectFB/EGLFS?

Oh, wait. Here it comes Qt:
class Window : public QWindow {
    QOpenGLContext *context;
public:
    Window() {
        QSurfaceFormat format;
        format.setVersion(3,3);
        format.setProfile(QSurfaceFormat::CoreProfile);

        setSurfaceType(OpenGLSurface);
        setFormat(format);
        create();

        context = new QOpenGLContext;
        context->setFormat(format);
        context->create();
    }
...
Yup, that's all. That creates a (toplevel) OpenGL window and a 3.3 Core Profile context. Combine it with a QTimer and you have a viable renderer. Which of course will work on all the above platforms: Win32, Mac, X11, Linux/EGLFS, QNX, iOS, Android.



Is there an overhead you have to pay for all of this? Yes, of course. But that's absolutely negligible; and you pay for it only once, i.e. when you create the window and the context.

The real heavy stuff comes from the OpenGL drawing itself, which is totally under your control: you make the context current on the window and start issuing raw OpenGL commands. Qt is not in the way there. The only moment when Qt and OpenGL will meet again will be at swap buffers time; but that's an operation that has virtually no cost.

So: Qt does not add any measurable overhead.

Window management

Of course, bundled with the above comes the fact that you can f.i. handle keyboard and mouse input with identical code across any of those platforms. Or resize the window. Or make it fullscreen. Or close it. 

OpenGL helpers

Qt doesn't "just" offer a way to create an OpenGL surface and context (and the related operations: set as current, swap buffers, etc.). It goes (much) further, and offers a whole array of helper classes and functions:


QMatrix4x4 is a... 4x4 matrix. Which has all the nice functions you need in an OpenGL program: lookAt(), ortho(), perspective(), normalMatrix(), and so on.
QOpenGLContext::hasExtension and QOpenGLContext::getProcAddress are platform independent ways of resolving OpenGL entry points.
QOpenGLContext::versionFunctions returns an object containing all the OpenGL entry point for a given version/profile already resolved.
QOpenGLBuffer wraps a buffer object.
QOpenGLVertexArrayObject wraps a vertex array object (and has a RAII helper to bind and unbind the VAO).
QOpenGLTexture wraps a texture object.
QOpenGLFrameBufferObject wraps a frame buffer object.
QOpenGLShader and QOpenGLShaderProgram wrap shaders and shader programs, offering convenience methods for f.i. setting a QMatrix4x4 as a uniform variable. So, you can calculate the MVP for a given mesh on the CPU using the methods mentioned above, then set it as uniform.
QOpenGLDebugLogger wraps GL_KHR_debug for debugging your OpenGL applications.
and another bunch of stuff I don't remember right now.


Is there an overhead? Yes, but once again it is minimal, and it does not involve how you use those objects in your OpenGL code. If your OpenGL code is fast and well structured, you'll find those helpers useful to manage it, and they won't make it run any slower.

(Example of "useful to manage it": QOpenGLVertexArrayObject will let you use a VAO on OpenGL 3.0, or on any Desktop OpenGL version where the GL_ARB_vertex_array_object extension is present, or on OpenGL ES2 if GL_OES_vertex_array_object is present. You don't need to resolve the right set of functions depending on the runtime. Qt will do that for you and provide the same APIs for creating, binding, releasing and destroying a VAO).

Is everything that good? No. I must be honest here, there are bits and bolts which would benefit from some love. 

For instance, QOpenGLFrameBufferObject has a limited API, not supporting f.i. any amount of color attachments. QOpenGLBuffer would need some work for supporting more buffer types / binding targets. There's still no support for program pipelines. There's still no support for uniform buffers.

On the other hand, you have things such as QOpenGLTexture, which supports quite recent features such as immutable storage and texture views. 

Does that mean you can't use those features? Of course you can. Just go back to raw OpenGL code if you need features Qt doesn't give you right now. Or, consider contributing those features to Qt!

Qt

Of course, once you go the Qt path, you have Qt. Which means, in the QtCore and QtGui libraries alone:


event loops
timers
signals and slots
threads
Unicode strings + i18n
containers
regular expressions
file handling
plugin loading
settings
mimetypes
input handling
image I/O
2d imperative painting using a raster engine
JSON
XML
and another bunch of stuff I don't remember right now.


Of course, all of the above is cross platform.

By the way, Qt also has:


QtWidgets for cross platform 2d widgets
QtSql for DB access
QtNetwork for TCP/UDP/SSL sockets, as well as a high level HTTP/FTP engine
QtTest for unit tests
QtWebkit for embedding webkit 
and another bunch of stuff I don't remember right now


OpenGL in Qt 4 vs 5

Are there any huge differences between how OpenGL is handled in Qt 4 vs Qt 5? Not really...

In Qt 4 the class to use to do OpenGL rendering was QGLWidget. It lived in the QtOpenGL module (and not in QtGui -- remember that in Qt 4 widgets lived in QtGui too). Also, what's actually a subset of the Qt 5 OpenGL helpers I listed above was available there under a QGLFoo name (f.i. QGLBuffer instead of QOpenGLBuffer).

In Qt 5 the QtOpenGL module is still there to keep old applications work. But:


QtGui and QtWidgets were split. QtGui now contains the low level bits to handle WM, creating GL contexts and surfaces, 2d painting, and basically the stuff I listed above. QtWidgets instead contains the widgets themselves.
QtOpenGL still contains the QGL* classes, but now links to QtWidgets (as it contains QGLWidget). This means that using QGLWidget means you'll link to a somehow big library even if you're not using widgets at all (because f.i. your app is pure OpenGL).
As I've shown before, QtGui is enough for creating a toplevel OpenGL window. But what if you want to embed it in a widgets-based application? Then you can still use QGLWidget or embed the QWindow via QWidget::createWindowContainer. Apart from QGLWidget, you shouldn't be using any other QtOpenGL (i.e. QGL) class. Use the counterparts in QtGui (i.e. QOpenGL classes). 
All the above QOpenGL* classes are in QtGui, not in QtOpenGL; and they are more than the QGL* counterparts (e.g. there's no QGLVertexArrayObject), they have more features (e.g. QOpenGLShader supports geometry and tessellation shaders, QGLShader doesn't), and in general the ones to use (as they will see bugfixes and improvements, the QGL* ones won't). 
Given that now QtGui offers OpenGL support, it would be natural to expect a QGLWidget replacement appearing directly into QtWidgets. And indeed it will, hopefully in 5.4 (the preparatory work is going into 5.3; but unfortunately the feature itself will miss the feature freeze).




Is there any reason for expecting a huge performance difference between Qt 4 and Qt 5? No. I expect your GL code to perform exactly the same. In the end Qt is not really getting in your way.

Desktop GL / ES 2

You can compile Qt 5 with either "Desktop GL" or "ES 2" support via a configure time switch.
It obviously will change which headers QtGui will use when compiling, and what libraries it will link to (libGL or libGLES2, etc.). It will also change the default surface format: the above QWindow code will create a nice OpenGL ES2 surface (and probably fail the context creation since there's no OpenGL ES 3.3, oh well).

But you get the point: with the same code you can also support ES2. 

The problem (in my opinion) is that it will also change some other more subtle stuff: for instance QOpenGLShader will insert some macros such as 
#define highp
#define mediump
#define lowp
before all your shaders if you're using Desktop GL. The reason is that it allows you to reuse the same shaders in ES2 and Desktop GL, which lacks the precision qualifiers; hence they get erased via macros that expand to nothing. 

I think these small things aren't really a gain. Maybe they reduce maintainance for very small and simple shaders (and programs made by only a vertex and afragment shader). It would have been better if Qt hand't tried to be so smart.

But your Desktop GL code path might be using more shader stages; or just in general be using features not available on ES2. Ultimately, it will significantly diverge from your ES2 code path. (Just think that in 3.3 Core you must use VAOs, while ES2 on its own doesn't eve know what a VAO is.)

Personal rant: I hate, hate, hate the fact that ES2 is not like an OpenGL profile or so, and instead sits on its own. And one must basically have a diverged code base just to make ES2 happy. Bah bah bah.

Windows

Enter the World of Pain! also known as the OpenGL driver status under Windows.

Basically, anyone but NVIDIA ships broken OpenGL drivers on Windows. 

At least, "out of the box". Upgrading the drivers usually works, but you aren't always in the position of asking the users to upgrade their drivers. They're end users, not pro-gamers. Maybe they don't even have administrator privileges.

This is a problem for OpenGL applications, and especially for one of Qt's strongest tools: Qt Quick 2. Qt tries to work around this problem by using ANGLE, which is a OpenGL ES2 -> Direct3D translation layer.  So, under Windows, you have the choice between


a Desktop OpenGL build
an OpenGL ES2 build via ANGLE


The choices are not equal -- ES2 of course means forgetting about doing any serious Modern GL. But apart from that, reasons for going one way or the other are available here.

Qt Quick 2

This is important and I think deserves a point on its own.

But first let's clarify things: do you need to use Qt Quick 2 to build an OpenGL application under Qt? NO, NO, and NO.  Qt Quick 2 is a totally independent technology which also leverages OpenGL for rendering. As such, you can ignore it and just build your OpenGL application.

But what's Qt Quick 2 exactly? It's a library built on top of the QML language, a declarative language born for creating dynamic UIs (and now used for build systems... oh well). 

Keep in mind the distinction: QML is the language, Qt Quick 2 is a library with a set of visual items (and C++ APIs for creating your own) which you program in QML. 

It happens that Qt Quick 2 uses OpenGL to draw those visual items. This guarantees nice 60 FPS tear-free results, very low CPU usage, all kind of shader-based eye-candy, and so on.

So what? Well, you might be interested at giving it a kick. For instance, the API allows it to be superimposed to any pure OpenGL content you draw. So you could think of using Qt Quick 2 for handing the more traditional UI bits -- buttons, sliders, etc., while you keep control of the rendering of the main content.

Or, you can just ignore the fact it exists and keep playing with OpenGL.

                        
这篇关于Qt 4/5和Opengl API之间的opengl速度差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！