
Qt Quick WebGL Streaming - ronjouch
http://blog.qt.io/blog/2017/02/22/qt-quick-webgl-streaming/
======
emcq
Back 5+ years ago Qt was my go-to framework for cross platform GUIs. You would
get the kitchen sink, but the abstractions provided were quite sane. Signals
and slots, nice OpenGL and painting libraries, reasonable asthetic and layout
options with snappy performance.

A while ago I entered a hackathon visualization challenge using Qt painter for
rendering. I expected C++ and Qt would slow me down but the rendering speed
and expansive drawing primitives were valuable! They greatly reduced my
iteration time and increased fun.

Today I never create new frontend projects with Qt. I may use Qt creator with
cmake for backend components, but the frontend is HTML and JavaScript with
libraries like React, Three.js, D3, and bootstrap. The experience is still
cross platform, but also one step away from launching as an internal portal.
Distribution this way is much easier, but the tools are so flexible you need
more diligence to keep the code maintainable over larger teams.

I struggle to see where you would prefer Qt for frontend code if you don't
need a native app.

~~~
problems
> I struggle to see where you would prefer Qt for frontend code if you don't
> need a native app.

How about actual native UIs instead of ugly, non-intuitive, slow and massive
Electron apps?

I say this being a dev who works with both Qt and Electron on a daily basis.
Electron has its place - but its place isn't good desktop and mobile apps. Qt
is much better suited there.

Electron is only well suited if your team is extremely familiar with web dev
but nothing else and you have no ability to hire a good desktop team or you
need to interact with a web-only frontend library.

Just about everything in Qt is preferable - native look and feel, proper
layouts, high performance rendering, small distribution size. I struggle to
think of any way in which Electron is better except for perhaps library
support these days.

~~~
sho_hn
> Electron has its place

Yeah, and it's called Hacker News - beyond that no one really cares, and uses
Qt.

This might sound like a troll, but the bubble effect on HN really is that
strong. The community sometimes has a strong tunnel vision and doesn't realize
how it's constrained by what's on the HN front page.

~~~
mumphster
Except for the millions of people using apps such as Slack or Discord or
people using the new Keybase desktop offerings, or people using Atom, or
VSCode.

Electron (sadly imo) is being used in plenty of newly developed cross platform
applications, a lot having users that have no clue what hackernews is.

~~~
problems
None of these apps feel quite right though. Even Atom still doesn't do DPI
scaling properly. VSCode does, but opening 2 panes sometimes causes it to
break.

Sample problem (left pane blurry, right pane sharp - view at 1:1 scale on
~100dpi screen to notice it easiest, but it's quite visible to me with scaling
even): [https://i.imgur.com/Ju0UK2K.png](https://i.imgur.com/Ju0UK2K.png)

~~~
zer0t3ch
I've never had any issue with Discord feeling "not quite right".

~~~
mememachine
You dont know what he means? They dont feel like native, they feel like web
apps.

~~~
zer0t3ch
I have noticed that with some Electron apps in the past, but I had actually
never noticed that with Discord. I thought it was native for the first 4
months I was using it because it was just done so well, no lag and such. The
one thing that usually gives away electron apps is their lack of custom right-
click handling, meaning a right-click will give you the generic context menu
you would normally see in a browser. Discord seems to handle all right-clicks
with their own context menus which is why I never caught onto it at first.

~~~
problems
Sample weird behavior from Discord:

Make the window too small and the buttons overlap in the titlebar. I didn't
even pick an extremely small size or anything, this was about half my screen
width on my Macbook. But this is the kind of thing that making a proper native
app forces you to think about, but that making an Electron app often doesn't.

[http://i.imgur.com/MOaESLC.png](http://i.imgur.com/MOaESLC.png)

I can pretty much tell within a minute of starting an Electron app because
things just don't feel right no matter what the app is. Sibling mememachine is
also pretty accurate - Discord is very oversized like many other Electron
apps.

Not using native platform widgets is also incredibly noticable. Every time
you're not using native platform buttons or menus it's so easy to tell, it
feels weirdly slow, has excessive gaudy animations, the spacing is wrong, text
size is wrong, etc. That's not to say that it can't be done right just that
you're on an existing platform and that consistency is key.

~~~
zer0t3ch
While you do raise some valid points, and some that I disagree with, I've
grown to appreciate such apps as of late. There was a time not long ago where
half the shit on my computer was Java because that was the only practical way
to make a decent cross-platform application without having to relearn
different things for each platform. Yeah, the whole "apps built on web-
technology" movement could use some refinement to reduce bloat and such, but
when done correctly, it seems to work out pretty well for the most part.

------
timdorr
Cached version:
[https://webcache.googleusercontent.com/search?q=cache:fGxLbP...](https://webcache.googleusercontent.com/search?q=cache:fGxLbPC4c68J:https://blog.qt.io/blog/2017/02/22/qt-
quick-webgl-streaming/)

------
wickedlogic
This touches on something I really want built into Synergy... a browser
instances as a synergy 'client' region, so I can seamlessly share KVM into
tablet devices on my desk. Then pair that up with something like TurboVNC to
connect to CloudTop machines. I wonder if I could use this/QT to fake that
client interaction and map the events into VNC session.

------
billconan
in 2014, i tried to develop a side project like this. Instead of streaming
OpenGL, I chosed to turn qt into video stream. I managed to stream qt apps
with OpenGL to browsers.

------
_pmf_
Basically, you get the intersection of the worst features of VNC and WebGL; a
particularly bad kind of hell (and I say this as someone who likes Qt).

------
n00b101
Similar idea as X Window client/server protocol (circa 1984). Similar
drawbacks: UI experience is subject to network latency and disruptions. It
also means you have to run the application on a server, in order to publish it
to the web.

The "ideal" solution would be to run the entire Qt/C++ application in the
browser, as a static "web page." This is can be done using WebGL and cross-
compiling C++ to asm.js/WebAssembly. There are several Emscripten demos
showing exactly that, with an ancient version of Qt [1]. But I guess the Qt
team has decided they don't want to support that direction (i.e. not even
trying to port Qt5 to Emscripten, but instead offering this "WebGL streaming"
thing)? Although, given how "heavyweight" Qt5 seems to be, I guess cross-
compiling the whole thing to WASM would result in something very inefficient.

Personally, I have been troubled by Qt's recent direction. First there was the
confusion of legacy QWidget vs. modern QML. A modern approach to UI
specification is welcome, though I question the need for embedding a
JavaScript engine when QML could have been compiled to native code. But the
real issue with QML is that the legacy QWidget approach was never really
depreciated, so Qt was no longer a coherent, unified approach to developing
UIs. Qt5 looks like two completely different UI libraries combined into a
confusing whole. The general spirit seems to be that desktop applications are
a second-class citizen in Qt, relegated to using legacy QWidget framework, and
the new QML framework is targeted towards mobile applications (the new first-
class citizen). This is unfortunate because users run most professional
applications on desktops with keyboard and mouse input, not on 6-12"
touchscreens. More recently, they decided that the whole "Qt Quick Controls"
line had terrible performance, so they were going to dump cross-platform
"native look & feel" (the original raison d'être of Qt) in favour of a "Qt
Quick Controls 2 [2]. Although, more recently, they seemed to be walking back
that "native look" decision (making the roadmap even more uncertain) [3]. If
the message to desktop developers wasn't clear enough already, the sparse list
of "Qt Quick Controls 2" [4] components that have shipped so far are squarely
aimed at simple mobile apps ("Drawer," "Switch," "SwipeView," etc) and is
missing basic components needed to build a desktop application (for example,
no promised release date for shipping a data table view component).

It turns out that this enormous edifice that has been built up, on top of Qt's
native C++ roots, is incompatible with the future direction that web browsers
are taking with WebAssembly and WebGL. While these browser developments are
proving to be a great thing for bringing OpenGL native applications to the web
browser [5], Qt seems to be left behind. They instead have to resort to
building this "WebGL streaming" functionality on top of an already teetering
stack, in order to deliver applications through the web in away that has
obvious drawbacks.

In my opinion, the C++ community should move past the Qt legacy and come up
with a new industrial-strength, cross-platform UI library that has
simultaneous first-class support for web, desktop, mobile and embedded
targets.

[1]
[http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...](http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-
qt/wiki/Demos)

[2] [https://blog.qt.io/blog/2016/06/10/qt-quick-
controls-2-0-a-n...](https://blog.qt.io/blog/2016/06/10/qt-quick-
controls-2-0-a-new-beginning/)

[3] [https://blog.qt.io/blog/2017/02/06/native-look-
feel/](https://blog.qt.io/blog/2017/02/06/native-look-feel/)

[4] [https://doc.qt.io/qt-5/qtquick-
controls2-qmlmodule.html](https://doc.qt.io/qt-5/qtquick-
controls2-qmlmodule.html)

[5] [https://floooh.github.io/oryol-samples/](https://floooh.github.io/oryol-
samples/)

~~~
ronjouch
> _But I guess the Qt team has decided they don 't want to support that
> direction (i.e. not even trying to port Qt5 to Emscripten, but instead
> offering this "WebGL streaming" thing)? Although, given how "heavyweight"
> Qt5 seems to be, I guess cross-compiling the whole thing to WASM would
> result in something very inefficient._

They do want to support that direction; see Lars Knoll's "Qt Project Status"
talk [1] from QtConf 2016. Talk about WebAssembly starts at 50:30 and also
mentions the recently-introduced QtLite as a potential path to your concern of
the "heavyweight" problem.

[1] [http://ftp.icm.edu.pl/packages/kde-
applicationdata/akademy/2...](http://ftp.icm.edu.pl/packages/kde-
applicationdata/akademy/2016/354_qt_project_status.mp4)

------
fulafel
This is pretty neat. What is the competition, do there exist other "browser
VNC" style stacks?

------
moondev
looks similar to gtk3+ broadway

[https://github.com/moondev/gtk3-docker](https://github.com/moondev/gtk3-docker)

~~~
mikewhy
As someone who has always loved the idea of thin-clients, this is super cool.

