On Friday 04 July 2014 13:41:28 Bernd Lamecker wrote:
> Hi,
>
> is there a special reason why you call
> setTimeout(function() { channel.exec({type: QWebChannelMessageTypes.idle});
> }, 0); (Line 179 & 197 in qwebchannel.js)
> via setTimeout? For me this also works without doing a singleshot.
> But the setTimeout function is not defined when including qwebchannel.js
> into a qml application.You can have a look at what I did in Client.qml in https://codereview.qt-project.org/#/c/81523/13//ALL - there I implement setTimeout in terms of a QML Timer object. Ugly and doesn't support multiple simultaneous calls to setTimeout, but at least it works. I really think we should have a setTimeout in QML, if alone to better support embedding external JavaScript libraries. Now, on the topic of _why_ I use setTimeout there: This comes from the original implementation of the QWebChannel we did for a customer of ours on an embedded platform which showed serious performance issues and scheduling problems, i.e. sending WebSocket messages repeatedly to a QtWebKit client completely hogged up the CPU in the WebSocket code and all other applications froze. This might need to be revisited, esp. considering that we'll get much faster QtWebKit IPC instead of WebSockets for the common case. So maybe, all of that is not required anymore. But before I blindly remove this stuff, I guess we should first work on the core functionality and then eventually cleanup such legacy code (and write more benchmarks etc. to verify we are not breaking anything). Bye -- Milian Wolff | [email protected] | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
