Desktop Client for EyeWire

Feature Requests
#1

EyeWire is a great tool for science. However, using web browsers as the platform was a horrible idea.

Would you guys ever consider porting the EyeWire over to the desktop?
Performance would skyrocket, and that is really the best reason to do it.

As a developer, I understand how long it would take and how much it would cost.
Please let us know if this on the menu.

1 Like
#2

Hey OneSmo, 


We actually do have a “version of EyeWire” for desktops that we use in the lab called “Omni”. You’re right, it is a lot snappier, but it also relies on a different software architecture and on our internal LAN to transfer huge amounts of data. It also comes without many of the features you associate with EyeWire (e.g. points, cubes, chat, etc).

I don’t think we’ve seriously considered giving Omni to the masses since it’s not as fun, and we haven’t streamlined the process for integrating the data with the EyeWire dataset. There is active development on it, but I think it’s pretty far away from a public deployment.

We are however considering ways to improve the speed of EyeWire itself and in the deepest secretest basements of the lab, we’re thinking of new game mechanics and ways to play. :slight_smile:

I hope that answers your question!

Will
EyeWire Developer

#3

I would also want a dedicated program for this. Even if it’s basically just a port from the webpage. I would think it’d solve a lot of problems people are having with compatibility, whether it has to do with their browser or extensions. 

Plus, you could probably integrate an option for grid computing, for those who are even more interested in contributing. 

#4

 I just recently found about Eyewire and I must say the project is very intriguing and well thought!

I will too voice my thoughts regarding a native OpenGL client. Using the web and WebGL was probably a very good idea in order to make Eyewire easily available to everyone/make it viral. But after a player is hooked/interested in helping out, there should be an option to switch to a native client that performs way better.

Consider that this would increase productivity of regular/resident players by a lot. My own observations are that I spend 80-90% of the time I need to complete a cube, in rotating, panning, zooming in and out the 3d model. This process is currently very slow and clunky. Notice that I am an independent game and software developer and I am currently playing on my main development system which is not only above average mainstream PC specs but actually an insanely fast platform both computationally and on the OpenGL/DirectX side of things. Web browser engines will always be the bottleneck in Eyewire productivity without a native client.

 Also I do not think that you should offer Omni, which I understand is your in-house application and not related to Eyewire, but rather directly replicate the web client in native code so anyone who tries Eyewire on the web and gets hooked can optin for a native client that performs great and allows them to complete cubes faster, providing a better experience. Just build a native client and tap into the existing Eyewire backend. If resources are limited, perhaps you can also consider starting an open source project for it since this is a research and not a commercial project.:slight_smile:


For now I will try using Chrome instead of Firefox because as far as I know Xulrunner’s WebGL performance is way worse.

 That said, congratulations for this project, it is extremely innovating and fun while also promoting science!





#5

I think that with any “non tablet” PC, performance is not an issue in 2014.

The browser is the best value for such a project, and compatibility is quite broad with modern browsers (MSIE, Mozilla Firefox, Google Chrome). Shifting to a dedicated app would mean either resurrect Google Gears, or find a WebGL implementation and build the app around it.

#6

Hey guys,


Thanks for writing in! For what it’s worth, there are two issues at play here. 1) We do have extremely limited development resources, so it’s not practical to build a native app for multiple targets. 2) Firefox uses software rendering for its WebGL implementation, so it’s very slow at times. If you’re having performance problems, try using Chrome as it uses hardware acceleration.

We are in the process of developing and documenting an API, so in the future it will be practical to create the kind of open source project you envision. However, going much bigger than EyeWire cubes will strain your bandwidth. In house, we use high speed LAN (1 gigabit / sec) for Omni cubes, but we can’t deliver that kind of performance over the global internet. There might be some clever caching tricks we can pull off in the future, but for now we’re sticking to 256 px^3 cubes.

Will Silversmith
EyeWire Developer
#7

Hello,

Thanks for the reply sapphiresun, your points are perfectly understandable. I do not think there is a reason to go for larger cubes anyhow.

I’ve found that setting webgl.prefer-native-gl in about:config in order to use native OpenGL instead of ANGLE DX wrapping, increases firefox performance and alleviates the frame latency issues that can be seen on firefox. Assuming the user is using a current tech video card with decent OpenGL driver. Perhaps you should offer this tip somewhere for Firefox users.

If resources allow it you should consider using asm.js. Recent ports of the Unreal engine to WebGL that utilize asm.js come very close to native code performance on Firefox. See also the Unity engine tests here:
http://blogs.unity3d.com/2014/10/07/benchmarking-unity-performance-in-webgl/