Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Turning Mesa Into JavaScript For The Web?

  1. #1
    Join Date
    Jan 2007
    Posts
    14,807

    Default Turning Mesa Into JavaScript For The Web?

    Phoronix: Turning Mesa Into JavaScript For The Web?

    Besides the recent talk about using Gallium3D's LLVMpipe for Mozilla Firefox, there's another interesting technical discussion happening now about using Mesa on the web to emulate the full OpenGL API using the WebGL API...

    http://www.phoronix.com/vr.php?view=MTA2NjY

  2. #2
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    962

    Default

    So this is to allow games written to use OpenGL to be played within a browser so wouldn't there a performance hit in doing that?

  3. #3
    Join Date
    Apr 2011
    Location
    Dhaka,Bangladesh
    Posts
    105

    Default

    Quote Originally Posted by DeepDayze View Post
    So this is to allow games written to use OpenGL to be played within a browser so wouldn't there a performance hit in doing that?
    There would be a great performance loss as nor javascript is as fast as C/C++ or webgl to opengl. Although I could think that its a quite interesting project. If in future, browsers could achive near native performence in graphics level, complex games could be created entirely on web and thus Linux users will also get a verity of game to play.

    Although I would like to see what the current status of the browsers. How much they will support right now heavy gaming. A benchmark will be much appreciate; Michael?

  4. #4
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,103

    Default

    With sites like github already laggy due to too much javascript, I'm certainly not looking forward to the day some site tries to force a few million lines of javascript down...

  5. #5
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    962

    Default

    Even if not strictly for games one interesting use from this project could even allow online collaboration on 3D graphics projects as well. If browsers could be beefed up to handle such JS code without too much of a hit in performance then cloud based games where the game code resides in the cloud and a client piece as a browser plugin/extension could be theoretically possible.

  6. #6
    Join Date
    Apr 2010
    Posts
    271

    Default

    Quote Originally Posted by DeepDayze View Post
    Even if not strictly for games one interesting use from this project could even allow online collaboration on 3D graphics projects as well. If browsers could be beefed up to handle such JS code without too much of a hit in performance then cloud based games where the game code resides in the cloud and a client piece as a browser plugin/extension could be theoretically possible.
    Oh, you mean Java Applets? That sounds like a great idea.

  7. #7
    Join Date
    Mar 2012
    Posts
    3

    Default Speed

    Hi everyone,

    Regarding speed, JS is indeed slower than C/C++. But it is getting fast quickly. Right now on several benchmarks JS is just 1.5x slower than C/C++. On most benchmarks JS is 2x-6x slower than C/C++. We are working hard to improve both the LLVM=>JS compiler and the JS engine itself, which should get most benchmarks to the lower end of that range - which would basically be as fast as Java, i.e. "fast enough".

    - azakai

  8. #8
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Not sure how useful this can really be given that most modern desktop OpenGL apps use various APIs and features that are not implemented in GLES/WebGL.

    Likewise, while emacripten is a neat hack, there are a great many limitations imposed by JavaScript that hampers the ability to port a lot of interesting C/C++ code, not to mention the massive overhead compared even to well-written native JS. (I gave a talk a few months back on optimizing JS game engines, and needless to say it requires a great deal of hand tweaking and low-level knowledge of the language that retargetting compilers abstract away from the programmer.

    A better solution would be to just get Firefox to support NativeClient. Especially as Unity 3D (an another two major game engines I can't disclose atm) are going to support NaCl as a target in the next year or so. Funnily enough, they're using that to claim Linux support without any "native" Linux binaries.

  9. #9
    Join Date
    Sep 2011
    Posts
    688

    Default

    Quote Originally Posted by DeepDayze View Post
    Even if not strictly for games one interesting use from this project could even allow online collaboration on 3D graphics projects as well. If browsers could be beefed up to handle such JS code without too much of a hit in performance then cloud based games where the game code resides in the cloud and a client piece as a browser plugin/extension could be theoretically possible.
    sounds like quark live.

  10. #10
    Join Date
    Mar 2012
    Posts
    3

    Default

    Quote Originally Posted by elanthis View Post
    Likewise, while emacripten is a neat hack, there are a great many limitations imposed by JavaScript that hampers the ability to port a lot of interesting C/C++ code, not to mention the massive overhead compared even to well-written native JS
    Actually, we are seeing that fully-optimized compiled code is faster than handwritten JS. For one thing, compiled code doesn't use GC at all. Also, it doesn't use objects which are hard to optimize; the code instead does low-level operations you wouldn't normally write in regular JS. But, JS engines can optimize that low-level stuff much better.

    For example, Box2D compiled with emscripten is significantly faster than Box2D's manual JS port. We see the same on most other benchmarks as well.

    A better solution would be to just get Firefox to support NativeClient. Especially as Unity 3D (an another two major game engines I can't disclose atm) are going to support NaCl as a target in the next year or so. Funnily enough, they're using that to claim Linux support without any "native" Linux binaries.
    NaCl isn't going to happen anywhere but Chrome - and even there, not sure it will be outside the Chrome App Store.

    NaCl is nonportable, which is the opposite of what the web needs. NaCl apps do not run on ARM devices, for example. Also, while open source, it depends on PPAPI. Those two technologies are nonstandard and basically controlled and constantly modified by Google, for that reason, no other browser vendor wants to touch them.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •