For Web code that needs performance, there's an alternative solution to
pushing it to server. This solution involves writing parts of code in C++
in format called PNaCl.
See this post for intro info:
http://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html?m=1
The limitation is that you will have to run it in Chrome browser, so iOS
might be problematic to support.
Regards,
Alex Bravo
On Jun 25, 2014 1:27 PM, "William Woodall" <
william@osrfoundation.org>
wrote:
>
> I haven't tried to implement anything, but my guess is that at least for
rviz, there are several places where a native app would out perform the web
version considerably. For example, transforming data between frames before
visualizing would likely be very intensive in javascript. You could push
most if not all of this into the server side which could be C++, but then
you run into the fact that websockets actually introduce considerable
overhead to communication when compared with ROS topics. This makes it a
bottleneck, for example the robotwebtools have things like the tf
republisher which takes /tf data and does some tricks to reduce the number
of messages sent. I believe this was developed because the websockets
couldn't keep up with /tf. I don't think the JSON data is the only reason
for increased bandwidth usage, but also the fact that it must go over http
requests.
>
> I'm sure about the custom shaders being available or needed, but I
imagine that the lack of them would make rendering things like pointclouds
much less efficient.
>
> For other tools like rqt_graph, rqt_topic, and other things I think the
web based tools make a lot of sense. You can work around access to local
files using the server for files on the target machine and you can access
files local to the browser's machine using html5 and javascript in some
cases. There are some awesome up and coming javascript libraries for data
visualization like d3js.org, which we have done some experimenting with
here at OSRF.
>
> --
>
>
> On Wed, Jun 25, 2014 at 1:05 PM, Vincent Rabaud <vincent.rabaud@gmail.com>
wrote:
>>
>> At ROS Kong, some rQt on the web was demoed as well as a Gazebo web
visualizer.
>>
>> I am no expert in web programing but what prevents us from moving rQt
and RViz to the web/javascript ? The obvious advantages would be
cross-platform support, optimizations independent of the underlying
libraries, easier code to debug, no compilation. Plus, there are already
great tools like robotwebtools and rosbridge.
>>
>> Here are a few reasons I was told that could prevent that move; are
those really valid ? Are there better reasons ?
>> - hard to access local files (html is not aware of local files)
>> - no customizable shaders in WebGL (is that the case ? do we need those
?)
>> - slow JSON parsing libraries (aren't those optimized in recent browsers
?)
>> - heavy bandwidth usage (how about binary JSON ?)
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users@lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>
>
>
> --
> William Woodall
> ROS Development Team
> william@osrfoundation.org
> http://wjwwood.io/
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)