Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Google Math Programming News

Julia Meets HTML5 129

mikejuk writes "Google labs has created a demo web page where fractals combine with HTML5 to give a fully interactive viewer that uses nothing but JavaScript and as many cores as you care to offer it and not a plug-in in sight."
This discussion has been archived. No new comments can be posted.

Julia Meets HTML5

Comments Filter:
  • by Anonymous Coward
    So why not hyperlink "Julia sets" to something telling us wtf a Julia set is [wikipedia.org]?
  • htm5 schmaTML5. I wrote a fractal viewer in TeX, in 1995. How's that for useless? http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=mandel [ctan.org]
    • by foobsr ( 693224 )
      I wrote a fractal viewer in TeX, in 1995.

      On a side note, fractint [fractint.org] (Quote: "Sometime in the spring of 1988 Bert Tyler bought a brand-new IBM PS/2 386/16. ...") is still around.

      CC.
  • by Kagura ( 843695 ) on Tuesday February 01, 2011 @10:23AM (#35067896)
  • "Google labs has created"... I think not. Actually I suspect talented people have created. How about their names?

    Or have they been totally borged?

    People create. Corporations monetize.

    • Corporations monetize.

      Um, didn't you just say that people are doing everything credited to the corporation?

    • by afabbro ( 33948 )

      "Google labs has created"... I think not. Actually I suspect talented people have created. How about their names?

      Or have they been totally borged?

      People create. Corporations monetize.

      It must be hard to walk with that staggeringly huge chip on your shoulder.

      We call it a Ford Fusion, or an Apple iPhone. If we listed all the people, it'd be a real pain.

    • by Ksevio ( 865461 )
      These days the Google engine is so powerful that it makes new experiments by itself.
  • And ? So what.

    I feel like I did after seeing Inception - that's it? Zzzzzzzz

  • by slim ( 1652 ) <john AT hartnup DOT net> on Tuesday February 01, 2011 @10:28AM (#35067962) Homepage

    It's nice, although not as quick as all that on my machine.

    But what does this demonstrate? Anyone interested knows you can display arbitrary graphics using HTML5 canvas. Anyone with any sense knows you can calculate a view of a Julia set in Javascript. Add the two together, and it's inevitable that this demo would be possible.

    Now, how about using Web sockets to set up some kind of P2P network whereby if someone else is viewing the same region as you are, your machines collaborate on the calculations...

    • by jfengel ( 409917 ) on Tuesday February 01, 2011 @10:46AM (#35068102) Homepage Journal

      I think the point is that Julia sets are compute-intensive, and they want to show off that "Modern browsers have optimized JavaScript execution up to the point where it is now possible to render in a browser fractals like Julia sets almost instantly" (to quote the web page rather than the freaking blog TFS linked to).

      The demo shows a count of "flops". It's hardly instant on my laptop (an elderly beast), and 20 megaflops isn't exactly making GPUs quake in their boots, but it implies that running Real Applications written in Javascript is a reasonable thing to do.

      • by slim ( 1652 )

        Hmm, except it's not a very satisfying speed experience on my machine, so it sort of undermines what I previously knew -- which is that a modern Javascript interpreter on a modern machine is pretty damn quick. ... and "real applications" generally aren't all that CPU intensive. Google Docs is a good demonstration that running real applications in Javascript is a reasonable thing to do.

      • The silly thing is, if you do it with a shader in WebGL you can do 3D raytraced fractals in real time in a browser. Doing this kind of thing in JavaScript really just shows how incredibly inefficient at number crunching JavaScript is. I mean, yes, you CAN do it... but really why should you? For the detail levels they're showing, a native application is 1000x* faster.

        *Not directly measured. But I have some experience in this area.

        • by jfengel ( 409917 )

          I think the goal is to show that it's fast enough for some compute-intensive applications. Five years ago, using Javascript for anything heavier than GMail and Google Maps was a dubious proposition; the first versions of the online office suites were bears.

          Flop-intensive applications may not be the best poster child for that, since it's not really fast enough for, say, a 3D first-person shooter. It's precisely the sort of thing for which native apps can still push the limits of a system. If they could ge

        • by Anonymous Coward

          Exactly. Try visiting ShaderToy:
          http://www.iquilezles.org/apps/shadertoy/

          2D/3D fractals which runs as shaders in WebGL.

      • HTML5, Now only 100 times slower than real applications!

        Seriously, 20MFlops in something like a julia/mandelbrot set is 486-level performance.

      • I think the point is that Julia sets are compute-intensive, and they want to show off that "Modern browsers have optimized JavaScript execution up to the point where it is now possible to render in a browser fractals like Julia sets almost instantly"

        Sure, if you're working at the top level (where it's not particulary compute intensive), but zoom down a few steps and it's suddenly as slow as molasses. (Slower than FRACTINT back on my old 386.)

        They make it look fast by limiting the number of iteratio

      • Anything fun is blocked on my work computer. I barely got over 1 megaflop (although the counter refresh is slow) but repeatedly using the page makes my Nexus One toasty warm.

    • by Jahava ( 946858 )

      It's nice, although not as quick as all that on my machine.

      But what does this demonstrate? Anyone interested knows you can display arbitrary graphics using HTML5 canvas. Anyone with any sense knows you can calculate a view of a Julia set in Javascript. Add the two together, and it's inevitable that this demo would be possible.

      Now, how about using Web sockets to set up some kind of P2P network whereby if someone else is viewing the same region as you are, your machines collaborate on the calculations...

      That and the Mandelbrot / Julia sets are awesome to explore, and they can now be explored from your browser with no dependencies. Something doesn't have to demonstrate a new or innovative use of technology to be cool and worthwhile.

      But this demo not only performs a significant number of floating-point calculations. It also utilizes several system cores, demonstrating (once again) the viability of an HTML5-equipped browser as an application platform.

    • > But what does this demonstrate?

      I think this can be used as a nice kind of benchmark... as others pointed out, this demo shows that a browser application is currently at the same speed of an old 386/486 native app (not bad IMHO, since a lot of great apps ran perfectly in that kind of system.)

    • 'Now, how about using Web sockets to set up some kind of P2P network whereby if someone else is viewing the same region as you are, your machines collaborate on the calculations...'
      Now we're talking! And an API for that while we're at it.
  • The HTML demo is here. [googlelabs.com]

    In other new, /. editors still fail the Turing test.

    • by gid ( 5195 )

      I word of warning, this crashed Chrome 9.0 beta, and killed off my keyboard and mouse. Ctrl-alt-del still worked and the mouse worked only when I was in this screen, so I was able to shut down cleanly.

  • One of the first things I ran on my shiny-new Commodore Amiga in 1985.

    • Mozilla seamonkey is broke and won't play it. It's supposed to be HTML5 capable?

    • This link works with Mozilla seamonkey. Nice - http://juliamap.googlelabs.com/ [googlelabs.com]

    • If this is the future of web apps, then I have no worries about the future native apps.

    • That 7 MHz 68000 CPU rendered a lot faster than my quad core Phenom does today.

      • >>>That 7 MHz 68000 CPU rendered a lot faster than my quad core Phenom does today.

        That's because most of the Commodore=Amiga Fractal demo was performed by the CPU's graphics coprocessor (multi-processing in 1985 - impressive eh?). Of course a modern PC also has a graphics coprocessor, so I don't understand why it would be so slow?

        Even now Amigas only need 500 megahertz and yet still equal the graphics/sound capability of a 2000+ MHz Mac or PC. (Playing youtube et cetera.)

  • Almost as slow as the new slashdot interface!

  • Either this is getting slashdotted and causing something to run slowly or what should be javascript running locally on my
    dmesg | grep CPU0:
    CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 01
    is slower than my old 486 at rendering a mandelbrot.
    I wrote my own viewer on an archimedes for a school project over 14 years ago and it was faster than this.
    Any clues?
    Or is this proof that browsers and scripts are only good for GUI and not actual processing?
    • by BZ ( 40346 )

      It really depends on the parameters used. For example, one important parameter for rendering the Mandelbrot set is the iteration count after which you decide that you're not escaping. Doubling this count will more or less double the time it takes to render. Happen to recall what you were using on your 486 for this value?

      There are other things you can do wrong in your code to make drawing the Mandelbrot set slow. For example, you can use objects to represent points on the complex plane (instant hit due t

      • For example, one important parameter for rendering the Mandelbrot set is the iteration count after which you decide that you're not escaping. Doubling this count will more or less double the time it takes to render.

        umm, no.. UNLESS the entire render is lake., AND there is no periodicity checking, AND ... (I could go on for awhile)

        I would have thought someone trying to come off as an expert would not have begun their "I'm smarter that you" post with something so obviously incorrect to anyone who has ever actually written a mandelbrot or julia renderer.

        Increasing the iteration count does not change the escape time of any point outside the set, and it is the outside of the set that people look at and zoom in on. All

        • by BZ ( 40346 )

          > umm, no.. UNLESS the entire render is lake.

          Usually the lake is the part whose rendering dominates the render time when rendering the entire Mandelbrot set, because most of the escaping parts escape pretty quickly. And the original post definitely sounded to me like it was talking about the full mandelbrot render.

          > AND there is no periodicity checking

          Which there isn't in the typical simple implementations (and in particular, there isn't in the Google code in question).

          > I would have thought someo

    • What resolution was your 486 rendering at?

      I don't know, I was pretty impressed that, as slow as this was, it was still reasonable on about half of my 1920x1200 display. I don't know that a 486 could even drive that big a display.

    • CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 01
      is slower than my old 486 at rendering a mandelbrot.
      I wrote my own viewer on an archimedes for a school project over 14 years ago and it was faster than this.

      You're doing it wrong

      I don't want to start a holy war here, but what is the deal with you HTML5 fanatics? I've been sitting here at my freelance gig in front of a PC (a box with two AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 01 processors and 16GB of RAM) for about 20 minutes now while it attempts to render a 17 Meg fractal from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this machine

  • ...it's neat. Nothing more, nothing less.

  • by jfengel ( 409917 ) on Tuesday February 01, 2011 @10:41AM (#35068068) Homepage Journal

    Here's a wacky idea: a link that is (a) not slashdotted, and (b) not to a blog posting.

    Google Labs [googlelabs.com]

  • And It performs awesomely! They need to stop smoking the banana peels and put the javascript down.

  • Just Google it, there are various years old implementations! http://blog.nihilogic.dk/2008/10/23-pretty-javascript-fractals.html [nihilogic.dk]
    • by slim ( 1652 )

      One thing that's sort of neat is how they've used the Google Maps libs for navigation. Check the source -- it loads the Maps JS directly from the Maps URL.

  • The demo is pretty; but Not Fast, even in the latest chrome on a dual-core A64. Not going to try it in FF on the netbook...

    It takes me back to the old days, of my misspent youth, when we grabbed somebody's Postscript fractal generator demo, set the number of iterations to something dubiously suitable to even the desktops of the time(it worked; but took about ten minutes) and then sent it to every postscript-capable printer we could locate across our school's network...
    • by slim ( 1652 )

      It takes me back to the old days, of my misspent youth, when we grabbed somebody's Postscript fractal generator demo, set the number of iterations to something dubiously suitable to even the desktops of the time(it worked; but took about ten minutes) and then sent it to every postscript-capable printer we could locate across our school's network...

      Hah. I once found a very short piece of Postscript which ray-traced a reflective sphere on a chess board. So I sent it to the office printer. I assumed I'd crashed it, but sure enough, 3 hours later, out pops the picture.

      • by Xtifr ( 1323 )

        Hah. I once found a very short piece of Postscript which ray-traced a reflective sphere on a chess board.

        Sounds like the one published by the ACM here [acm.org]. A boggling 762 bytes of PS.

    • by Fnkmaster ( 89084 ) on Tuesday February 01, 2011 @11:32AM (#35068574)

      Nothing quite like calculating and rendering fractals in Javascript to make your Core i7 feel like a Pentium 200.

    • Running on a Xeon E5520 here, with a decent nvidia workstation graphics card running Chrome's dev channel, and still doesn't perform particularly well.
  • by Timmmm ( 636430 )

    I hate to say it, but javascript and canvas are disappointingly slow. XaoS is dozens of times faster than this, and while I'm sure a lot of it is to do with specific fractal optimisations, surely a significant factor is the slowness of pixel operations and drawing images.

    I'm writing an HTML5 game, and simply drawing an image that fills the screen (with no resampling) brings you down to about 50 fps. A few more small images, some resizing later and I'm into the 30 fps realm, and that's on a really fast compu

    • I'm sure that the speeds will improve over time. Part of it has to do with the execution time of Javascript which has a lot to do with how fast things run in Firefox (at least from my experiences with FF). That, and the browsers are likely not using the fastest methods for drawing to the canvas elements.

      Browser developers are dipping their toes in the water at this point because HTML5 isn't standardized yet, but there's a growing interest in what it can do. Of course, on top of supporting these new standard

  • Excellent demo though :)

    [John]

  • I got nothing. Lame IE8 here at work and Julia Map opens to a big blank screen with a grabber hand...nuthin'.

    If it doesn't "just work" it won't gain traction.

  • Oh, a fractal viewer. Or more specifically, a Julia set viewer.

    Would have been nice to know what sort of a viewer this was by the summary. After all, it's not like there are other things named Julia or that fractals have been used for other types of viewers [wikimedia.org].
  • It only goes to a zoom level of 50. Hmm!
    • It broke at zoom level 33 for me. Everything just disappeared, window went white (controls were still there and working) no matter what part of the fractal I zoom in on.
  • Instead of trying so hard to optimize JavaScript to do things like that, why can't we just get a wider language choice? Like, a properly sandboxed language with static typing could be handy, and the standard could mandate its presence. Everybody would get a compatible browser eventually, if it allowed them to run web apps that are actually fast.

    • Instead of trying so hard to optimize JavaScript to do things like that, why can't we just get a wider language choice? Like, a properly sandboxed language with static typing could be handy, and the standard could mandate its presence.

      Its not going to happen in the HTML standard the way that standard process works -- which essentially gives a veto to any browser maker with a measurable usage share -- Mozilla & Opera probably wouldn't want to implement anything along those lines, Microsoft would insist on .NET, and Google would probably propose something like Portable Native Client.

  • It doesn't work past about zoom level 48-50. Fractals aren't supposed to have bottoms.
    • It probably reached the limit of the CPU floating point precision -- unfortunately javascript doesn't have arbitrary precision.

      If each zoom step is 2x (as it appears to be), at the 54th zoom level the distance between each adjacent pixel is 1/2^54 of the same thing at the starting zoom level. 64-bit precision floating point numbers (probably what javascript uses) have 53-bit precision for the mantissa, so at zoom level 54 the precision is not enough to tell apart two adjacent pixels. You probably see the pr

  • Our Real-World HTML5 Benchmark [clubcompy.com] at ClubCompy had a Julia set running in the browser a full month ago!

    It's not a fair comparison though that they're so much faster than us, our code runs out of a BASIC-like language called Tasty that runs ATOP JavaScript.

  • Go here: http://mandelbrot.is.rly.gd/ [is.rly.gd]

    I created this a couple years ago to explore custom rendering of tiles on Google Maps. Neat that they're doing it all in JS - my version is entirely rendered server-side!

  • That's 0.01% of the computing power of my machine.

  • in FF 3.6 it is dog slow... in Google Chrome 10 it is passable.

    • by slamden ( 104718 ) *
      It's considerably faster in Chrome than FF 3.6 for me as well. I noticed that Chrome manages to really max all four of the cores on my processor at once, while FF does not. I guess this is a pretty good tech demo for how well Chrome can distribute a heavy processing load.
  • What? (Score:4, Insightful)

    by Trogre ( 513942 ) on Tuesday February 01, 2011 @07:23PM (#35074796) Homepage

    Great, now I can render the Mandelbrot set on my dual-core 4800+ box nearly as fast as I could on my 386 with FractInt.

    I wish I was kidding, but if this is a representative demo of HTML5 then we're in trouble.

Garbage In -- Gospel Out.

Working...