Hi;
You want to send this email to gtk-devel-list, if you want to reach the GTK development team.
Additionally, you have to keep in mind two things related to the Broadway GDK backend:
- the rendering model of GTK has dramatically changed in GTK 3.9x (and thus in GTK 4.0); this means that the Broadway backend in the current development branch of GTK is barely functional. There is currently no effort being directed at Broadway; unless somebody steps up, the backend is likely to be removed in the next major API version.
- Broadway has always been a kind of "science experiment"; it kind of works, if you know exactly what you're doing, and if you accept the limitations of the implementation; even in the 3.x API it's a "best effort" code base that survives mostly because it has minimal impact on the rest of the toolkit.
Any work towards making Broadway work ought to be directed towards adapting it to the new GTK rendering model, based on GSK and (possibly) hardware accelerated rendering.
If you wish to contribute to the development of Broadway, please feel free to pick up the master branch, and join the #gtk+ IRC channel on irc.gnome.org.
Ciao,
Emmanuele.
On Wed, 7 Jun 2017 at 22:49, chrysn <chrysn@xxxxxxxx> wrote:
Hello GTK list,
with WebAssembly becoming a fixed part of modern browsers, this opens a
new execution environment for GTK applications.
The emscripten library already provides an environment where C programs
can be compiled with minimal modifications to run in the browser;
emscripten provides a virtual file system and an SDL2 implementation for
them.
I imagine (and that's why I prefixed the thread with "vision", though
the subtext of madness is fitting too) that in Broadway the trip through
the web socket could be cut short: rather then buffer updates being sent
via websockets, they could be sent via WebAssembly syscalls right into
the Broadway _javascript_ page that is fully hosting the WebAssembly
application rather than just opening a socket to one.
This would allow for some applications to run completely standalone in
the browser (eg. games[1]), while others could shift much workload from
the application server to the client (the terminal server for Evolution
would not need to run an instance for each user any more, but only
statically serve the executable and then act as file system and
networking gateway).
I think this would be possible to implement; do you think it would be
practical, and for which applications?
Best regards
chrysn
[1]: The few file accesses those have can be served from a read-only
statically shipped file system, or one could take the game further to
gio and implement a dav:// with "system calls" to XMLHttpRequest...
--
I shouldn't have written all those tank programs.
-- Kevin Flynn
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list
--
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
