QtQuickWebGL在Qt5.12中正式发布
Qt Quick WebGL在Qt 5.12中正式发布
本⽂翻译⾃原⽂作者：校审： Qt 5.12⼀个新功能是Qt Quick WebGL平台插件（之前称为WebGL streaming）。之前曾在Qt 5.10中发布了技术预览版，从Qt 5.12开始，它是⼀个正式发布的功能。这篇⽂章有点长，所以列个⽬录先。
简⽽⾔之
$ ./your-qt-application -platform webgl:port=8998
介绍
推荐您参考以下⼏篇介绍WebGL英⽂版博⽂：
软件开发和UX设计供应商ICS的Jeff Tranter也曾经写过。本⽂是从普通的Qt“⽤户”⾓度出发的“拆箱”体验描述 —— 我从未亲⾃试⽤过Qt Quick WebGL streaming，也没有参与其开发。
什么是WebGL streaming
如果您曾阅读上⾯提到的⼏篇博⽂，请跳过此段落。但我仍然建议阅读。 WebGL streaming是⼀个，它通过⽹络发送Qt Quick应⽤程序的OpenGL调⽤（“流式”），然后将这些调⽤转换为的调⽤，从⽽可以在中渲染。这就让您可以在远程主机上运⾏应⽤程序，并在本地Web浏览器中呈现其GUI。以下是它的⽰意图：
还有⼀个来⾃KDE Akcademy的视频，以及来⾃的详细讲解。但因为我是初级Qt“⽤户”，所以并不关⼼其中隐藏的细节，我的理解如下：
我可以在某些设备上运⾏基于Qt的应⽤程序，或者说在我的iPad上使⽤Safari运⾏Qt程序。听上去不错。当然，这个设备（此处指树莓派）可能是指⼀台“托管”应⽤程序的桌⾯电脑，但我认为WebGL streaming主要⽤于嵌⼊式平台（参见之后的章节）。现在让我来重点介绍⼀下前⾯说到的⼏个特性：
应⽤程序本⾝不在 Web浏览器中运⾏。Web浏览器仅渲染其GUI;
所以它既不是视频流，也不是镜像。它是在Web浏览器中显⽰的“解耦”的应⽤程序的GUI;
由于它仅适⽤于OpenGL（ES），因此WebGL流不适⽤于Widgets或任何其他⾮OpenGL内容。
事实上如果您尝试使⽤WebGL QPA启动某些“不兼容”的Qt应⽤程序，很可能会出现以下的错误：
qt.qpa.webgl: WebGL QPA platform plugin: Raster surfaces are not supported
如何使⽤
您只需要安装它：
如果您不是利⽤安装包安装，请照常从构建Qt，构建过程⽆需特殊配置。实际上在早期版本中，必须使⽤-opengl es2选项，但是现在不再需要了，因为即使安装了更⾼版本的OpenGL，仍可以使⽤ES这个⼦集。安装Qt后，您可以构建任何Qt Quick应⽤程序，并使⽤以下命令⾏参数启动它:
$ ./your-qt-application -platform webgl
您不需要在源代码中进⾏任何修改，它就能运⾏。在Web浏览器中打开以下地址：127.0.0.1:8080，127.0.0.1是运⾏应⽤程序的主机IP地址。如果要使⽤其他端⼝，可以像下⾯这样指定：
$ ./your-qt-application -platform webgl:port=8998
⽏庸置疑，Qt WebGL是跨平台的，它可以很好的兼容Linux，Mac OS和Windows。只是启动应⽤程序的⽅式有⼀些差异： Linux：
./your-qt-application -platform webgl:port=8998
MacOS：
QT_QPA_PLATFORM=webgl:port=8998 ./your-qt-application.app/Contents/MacOS/your-qt-application
...因为我现在⽤的这版Qt显然忽略了-platform选项（这听上去像是需要报告的bug）。 Windows：
< -platform webgl:port=8998
当然您也可以使⽤⼀种跨平台的⽅式（讲究）来实现，在main.cpp中使⽤qputenv()⽅法
// ...
qputenv("QT_QPA_PLATFORM", "webgl:port=8998");
QGuiApplication app(argc, argv);
// ...
在⽹络浏览器的⽀持⽅⾯，我尝试了⼏个浏览器（除了某个⽤trident内核的和他的⼩兄弟之外）都能运⾏，看起来WebGL在现代浏览器中得到了很好的⽀持。虽然我确实偶尔经历了⼏次页⾯重新加载，并且在基于Android的平板电脑上，Chrome甚⾄崩溃了⼀次。显然它不算完美，但这确实超出了Qt的
覆盖范围。关于性能，最“忙”的时间是在web浏览器正在接收缓冲区、纹理、字形、地图集等数据的初始化阶段。在第⼀次绘制调⽤之后，带宽使⽤率就⾮常低。顺便说⼀句，由于OpenGL ES调⽤是作为⼆进制数据发送的，因此它应该⽐VNC更“轻量级”。我实际上正在考虑再写⼀篇博⽂在⽹络利⽤率⽅⾯把WebGL streaming和VNC做⼀次⽐较。
⽰例
在以前的博⽂中已经有相当数量的演⽰视频，这⾥也有⼀个不错的，今天我来补充⼏个我⾃⼰的。
设备信息
我们也可以在这⾥看看⽤户的输⼊事件：
因此应⽤程序确实在树莓派上运⾏，⽽我在浏览器中所拥有的只是它的“流式”GUI。
相机
这个演⽰更加实⽤：由机器⼈⼿臂控制的相机安装在树莓派设备上：
⽬的是通过设备端基于Qt的程序来控制摄像机（平移和倾斜），⽽现在是通过某个平板电脑上的Web
浏览器远程执⾏此操作。我们希望看到相机的取景器内容，或者⽤机拍照也很不错。以下是此类设置所需的硬件列表：
。我也可以选择树莓派Zero，但这款HAT更适合“全尺⼨” 树莓派;
这就是我⽤来组装它的。现在我说点题外话（剧透：接下来我要安利Qt商业版功能）。您可能已经注意到，对于的演⽰，我使⽤了的镜像。在它的帮助下，在向树莓派构建和部署基于Qt的应⽤程序的过程中节省了我相当多的时间和精⼒。但Boot to Qt是商业版特性，如果没有它，您必须采取更多步骤来设置系统环境。以常规镜像为例，您需要做如下⼯作：
由于使⽤了Qt Multimedia模块，您需要确保系统中已安装，并且您已安装了正确的插件;
获取树莓派的最新Qt版本（12）。在桌⾯上设置交叉编译⼯具链或在设备上构建它。直接在树莓派上从源代码构建Qt实际上是⼀个不错的选择（特别是如果您使⽤交叉编译⼯具链遇到错误），虽然编译本⾝需要⼤约10个⼩时并且需要增加可⽤的swap分区尺⼨（1 GB 的RAM真⼼不够）;
构建驱动程序，使GStreamer和Qt可以发现相机;
想出⼀种在设备上构建/部署应⽤程序的便捷⽅法。
虽然这个步骤列表看起来不是太长，但实际上它可能需要您⼏天的时间，如果使⽤Boot to Qt镜像，您将获得开箱即⽤的体验，并且您可以在Qt Creator上直接连接设备，运⾏您的应⽤程序。商业推⼴结束，让我们回到演⽰上来。 GUI布局如下所⽰：
第⼀个选项卡上的⼤部分空间由相机的取景器占据，该取景器通过和本⾝实现：
Camera { id: camera }
VideoOutput {
anchors.fill: parent
fillMode: VideoOutput.PreserveAspectCrop
source: camera
}
它有⼀个⽔平和⼀个垂直的—— ⽤于控制摄像机云台的左右和上下：
Slider {
id: sliderTilt
orientation: Qt.Vertical
from: root.maxValue
value: 0
stepSize: 1
to: -root.maxValue
onPressedChanged: {
if (!pressed)
{
}
}
}
Pan-Tilt HAT伺服系统是通过接⼝⼯作的，由于时间原因，我使⽤Pimoroni的来快速解决。在某些时候，我甚⾄想⽤C / C ++优雅地重构该功能，但它并⾮此次演⽰的重点。还有⼀个控制拍照的：
Button {
scale: hovered ? (pressed ? 0.9 : 1.1) : 1
background: Rectangle {
color: "transparent"
}
Image {
anchors.fill: parent
source: "/img/camera.png"
}
onClicked: {
camera.imageCapture.captureToLocation(basePath + "shots/" + getCurrentDateTime() + ".jpg");
}
}
第⼆个标签包含了拍摄的照⽚列表：
...⽤实现：
ListView {
FolderListModel {
folder: "file:" + basePath + "shots/"
nameFilters: ["*.jpg"]
}
model: folderModel
delegate: ItemDelegate {
text: model.fileName
web浏览器在哪里打开}
}
提供完整的应⽤程序源代码。现在让我们看看它的实际效果。我的桌⼦上围着相机放着3个精灵头像，我想拍⼏张照⽚。我在设备上⽤参数-platform webgl构建并运⾏应⽤程序，并通过iPad上的Safari通过Wi-Fi连接到应⽤程序：
正如您所看到的，结果很好，看到相机的取景器，我可以远程控制它的位置并拍摄我感兴趣的物体的照⽚。
⽤例
WebGL streaming最有⽤的⽤例是能够为⼀些具有有限计算能⼒的低端设备提供合适的GUI且⽆需GPU，甚⾄很多情况下这些设备根本没有任何显⽰功能。例如，在⼯业⾃动化领域常见的场景中，您可以在整个⼯⼚安装⼤量⽆显⽰的设备：它们可以分布在相当⼤的区域，甚⾄可以安装在有危险环境的地⽅ —— 如果能够对这些设备进⾏远程控制和配置那就⾮常实⽤了。在读上的讨论时，我突然产⽣了⼀个“相反”的想法：如果“设备”实际上是⼀个⾮常强⼤的服务器，您可以在常规电脑上的Web浏览器中使⽤GUI时在服务器上执⾏⼀些繁重的计算（实际上需要基于HTML的前端，将在中详细讨论）。另⼀个可能的⽤例是反盗版措施。假设您希望保护您的软件不被“破解”或“盗版”。显然，如果客户端上没有运⾏，那么没有什么可以破解，因为您的⽤户只在其浏览器中呈现GUI，并且应⽤程序本⾝正在您的服务器上运⾏。听起来不错但是有⼏个缺点：
虽然WebGL streaming在本地⽹络中表现良好，但通过互联⽹使⽤它会导致显著的延迟;
连接未加密，因此不安全;
⽬前，⼀次只⽀持⼀个连接（也就是说只有⼀个⽤户）。
总的来说，⼀次仅⽀持⼀个连接⼤幅减少了应⽤场景，遗憾的是，该功能当前在实现中不太可能得到改进，这可能是中需要完成的⼀个任务。顺便补充⼀点，流式传输可以实现屏幕镜像功能，因为在某些场景下，镜像功能⾮常重要。谈到屏幕镜像，我想提⼀下我们最近与韬睿合办的。在那⾥，您可以
看到WebGL streaming和的有趣组合，它允许您实现上述所有功能。 WebGL streaming的另⼀个值得注意的⽅⾯是所谓的“零安装”概念 —— 您不必在客户端（台式机/平板电脑/智能⼿机/等）上安装/部署任何东西，因为唯⼀需要的只是⼀个Web浏览器。但是，似乎更适合这个⽬的。 WebGL streaming与传统web技术的⽐较有些⼈可能会问，WebGL streaming存在的根本价值在哪⾥？因为它是运⾏在web浏览器上的技术，⼈们完全可以使⽤常规的web服务器并创建⼀个web应⽤程序 —— 结果⼏乎是相同的：后端托管在远程设备上，基于HTML的前端在web浏览器中渲染GUI。这是⼀个⾮常好也很公平的问题。我实际上有⼀些⽹络开发的经验，所以我⾃⼰提出了这个问题。让我试着回答⼀下，希望不要引起另⼀场圣战。实际上，在某些情况下，只需要⼀个简单的REST API就⾜够了，特别是如果您只需要获得⼀些纯⽂本数据值。因此，在此类场景中基于Qt的WebGL streaming应⽤可能会被秒杀。但是，在更复杂的场景中（例如，当您需要控制某些硬件时），可能更适合使⽤基于Qt WebGL streaming的 GUI应⽤程序，因为这样您将获得强⼤的后端（基于C ++ / Qt），使⽤Qt Quick⽐HTML / CSS / JS 创建⼀个复杂、有吸引⼒且⾼性能的前端更容易（相当简单），但这个结论看起来像是另⼀场圣战的开始，所以我会把它当作我的个⼈意见。最后值得⼀提的是，如果您已经拥有⼀个基于Qt的应⽤程序，那么WebGL streaming是⼀个显⽽易见的选择，因为它可以让您不需要花费任何成本地拥有⼀个远程GUI。
许可/定价
WebGL streaming插件可在商业和开源许可下使⽤（但仅限GPLv3）。对于商业客户⽽⾔，它包含在应⽤程序开发和设备创建产品中，⽆需额外费⽤。
结论
================ End

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。