Slashdot Mirror

← Back to Stories (view on slashdot.org)

Julia Meets HTML5

Posted by CmdrTaco on from the keep-on-zooming dept.

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."

95 of 129 comments (clear)

  1. The article is on a webpage. by Anonymous Coward · · Score: 2, Informative

    So why not hyperlink "Julia sets" to something telling us wtf a Julia set is?

    1. Re:The article is on a webpage. by Kozar_The_Malignant · · Score: 3, Informative

      Sorry, this is "News For Nerds." Nerds know what a Julia set is.

      --
      Some mornings it's hardly worth chewing through the restraints to get out of bed.
    2. Re:The article is on a webpage. by History's+Coming+To · · Score: 2

      And how to spell it in a headline.

      --
      Please consider this account deleted, I just can't be bothered with the spam anymore.
    3. Re:The article is on a webpage. by slim · · Score: 1

      Why didn't you "hyperlink" to something telling us wtf a hyperlink is?

    4. Re:The article is on a webpage. by Nadaka · · Score: 1

      ... The Julia set and fractals are math, pure math.

    5. Re:The article is on a webpage. by Anonymous Coward · · Score: 1

      I'm sorry but I'm a nerd and I didn't know about Julia. If they had said Mandelbrot I would have known it was fractals by the title alone.

      "I'm sorry but I'm a chess player and I didn't know about Knight movements. If they had said Horsey piece I would have known what it was by the title alone."

      Me thinks the second part of your sentence disproves the first part of it...

    6. Re:The article is on a webpage. by wideBlueSkies · · Score: 1

      Julia's got a great set allright.

      --
      Huh?
    7. Re:The article is on a webpage. by Dabido · · Score: 1

      Because true geeks not only know what they are, they also independently discovered them at the age of five before going on to solve Fermat's last theorem on a piece of toilet paper.

      --
      Sure enough, the cow costume was hanging up next to the superhero outfit and sailors uniform. (S,Spud)
  2. pah! by MancunianMaskMan · · Score: 1

    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

    1. Re:pah! by foobsr · · Score: 1

      I wrote a fractal viewer in TeX, in 1995.

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

      CC.

      --
      TaijiQuan (Huang, 5 loosenings)
  3. Link missing from summary. by Kagura · · Score: 3, Insightful

    Here's the link to Google Labs' . Also, there's an obvious typo in the summary title. I'm unhappy with Slashdot lately.

    1. Re:Link missing from summary. by mikejuk · · Score: 1

      Sorry about the typo - I screwed up and hit save before I could correct it. I also forgot to put the link in - not a good day for me.

    2. Re:Link missing from summary. by Kagura · · Score: 1

      I even screwed up my comment about it. Stuff happens, sometimes.

  4. Who? by DeathSquid · · Score: 2

    "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.

    1. Re:Who? by MightyYar · · Score: 1

      Corporations monetize.

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

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    2. Re:Who? by afabbro · · Score: 1

      "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.

      --
      Advice: on VPS providers
    3. Re:Who? by Ksevio · · Score: 1

      These days the Google engine is so powerful that it makes new experiments by itself.

  5. Re:Link missing from summary. Fixed by Kagura · · Score: 1

    Here's the link to Google Labs' Julia Map. Also, there's an obvious typo in the summary title. I'm unhappy with Slashdot lately.

  6. Re:J u i l i a ? by jdpars · · Score: 1

    Maybe some alternative Italian spelling?

  7. Re:html5 by MosX · · Score: 5, Informative

    The canvas tag is a part of the HTML5 spec. So it is an HTML5 application.

  8. Why is this surprising? by slim · · Score: 2

    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...

    1. Re:Why is this surprising? by jfengel · · Score: 3, Insightful

      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.

    2. Re:Why is this surprising? by slim · · Score: 1

      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.

    3. Re:Why is this surprising? by Jahava · · Score: 2

      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.

    4. Re:Why is this surprising? by fractalus · · Score: 1

      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.

      --
      People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
    5. Re:Why is this surprising? by jfengel · · Score: 1

      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 get Doom running in an HTML5 box, that would be a demo worth watching.

    6. Re:Why is this surprising? by imsabbel · · Score: 1

      HTML5, Now only 100 times slower than real applications!

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

      --
      HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
    7. Re:Why is this surprising? by DerekLyons · · Score: 2

      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 iterations and by using a calculation method that draws a 'draft' version first and then goes back in and repeats the calculations (increasing the detail level) while you're going "ooh shiny" over the not very detailed 'draft'. They've taken a page from FRACTINT for that - this method was included in the program specifically as a method of quickly creating a low fidelity rendering so the user could quickly search for interesting locations that would then be re-examined using methods that were computationally intensive.
       
      I.E. it's a demo rigged to *look* spiffy and shiny, but if you have any actual under-the-hood knowledge you can see right through the smoke-and-mirrors.

    8. Re:Why is this surprising? by DiegoBravo · · Score: 1

      > 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.)

    9. Re:Why is this surprising? by Anonymous Coward · · Score: 1

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

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

    10. Re:Why is this surprising? by Gadgetfreak · · Score: 1

      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.

      --
      "No fair, you changed the outcome by measuring it!" - Professor Hubert J. Farnsworth
    11. Re:Why is this surprising? by samdutton · · Score: 1

      '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.

  9. Original link by kiwix · · Score: 1

    The HTML demo is here.

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

    1. Re:Original link by gid · · Score: 1

      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.

    2. Re:Original link by foobsr · · Score: 1

      It crashed Firefox 3.6.13 (LMDE, 2.6.32-5-amd64) as well, but only the browser.

      CC.

      --
      TaijiQuan (Huang, 5 loosenings)
    3. Re:Original link by quantumphaze · · Score: 1

      Didn't crash my Firefox 3.6.13 but it is using over 400MB of RAM.

      --
      Unicode in Slashdot
  10. Ahhh fractal demos by commodore64_love · · Score: 2, Informative

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

    --
    "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    1. Re:Ahhh fractal demos by commodore64_love · · Score: 1

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

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    2. Re:Ahhh fractal demos by commodore64_love · · Score: 1

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

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    3. Re:Ahhh fractal demos by icebraining · · Score: 1

      Gecko has support for canvas for years now. Have you tried other pages with canvas?

      --
      Dilbert RSS feed
    4. Re:Ahhh fractal demos by Mr.+McGibby · · Score: 1

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

      --
      Mad Software: Rantings on Developing So
  11. Wow by Executive+Override · · Score: 1

    Almost as slow as the new slashdot interface!

  12. Gave up waiting by sce7mjm · · Score: 1

    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?

    1. Re:Gave up waiting by BZ · · Score: 1

      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 to the extra costs of property access involved), you can make your complex operations allocate new objects (instant hit for obvious reasons). You can use a slow escape test (e.g. something involving square roots). In this case, using workers, you could spend too much time sending data back and forth a dribble at a time instead of computing a bunch and batch-sending it. Their code is obfuscated enough that I can't tell exactly what they're doing with their worker communication offhand; it looks at first glance like they compute (256/f)^2 points at a time in a worker, where f is the "pixelSize" argument to the worker.

      Looking more at their worker code, they seem to not be using objects, seem to be using 1000 iterations as their "does not escape" criterion, and seem to be using "norm squared is at least 10000" as their escape test (which is nuts for mandelbrot, but they're using this function as a general backend for all the fractals involved, and for the Julia sets testing norm squared against 4 won't cut it, whereas it would for the Mandelbrot set). So they're not doing this in the slowest way possible, but neither is the code particularly optimal for computing the mandelbrot set.

      Outside the code, there are several things your _browser_ could be doing wrong. You never said what browser you're using, exactly. So for one thing it's not clear whether the browser involved has a functioning jit or whether it's interpreting the JS. It makes a huge difference. You also never said whether your browser supports Web Workers or not; if it does not then you're only using one of your cores, of course.

    2. Re:Gave up waiting by Rockoon · · Score: 1

      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 the interesting areas has little no no lake at all in them.

      --
      "His name was James Damore."
    3. Re:Gave up waiting by SanityInAnarchy · · Score: 1

      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.

      --
      Don't thank God, thank a doctor!
    4. Re:Gave up waiting by BZ · · Score: 1

      > 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 someone trying to come off as an expert

      I wasn't "trying to come off as an expert"; I was just pointing out a small set of things (not at all exhaustive, nor trying to be, because I am NOT an expert on this topic) that matter for comparing performance of simple Mandelbrot renderers.

      > All the interesting areas has little no no lake at all in them.

      I think your expertise in rendering the mandelbrot set is making you blind to the fact that most timing tests people do are really simplistic. In particular, people tend to form performance snap judgements based on the default settings of the demo; in this case that's rendering the entire mandelbrot set. I realize that's not what you do, but I'm willing to bet that's what the original poster did....

    5. Re:Gave up waiting by quantumphaze · · Score: 1

      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, the same operation would take about 2 minutes. If that.

      In addition, during this fractal transfer, Minecraft will not work. And everything else has ground to a halt. Even Safari is straining to keep up as I type this.

      I won't bore you with the laundry list of other problems that I've encountered while working on various HTML5s, but suffice it to say there have been many, not the least of which is I've never seen a HTML5 that has run faster than its native counterpart, despite the JavaScripts' faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 2x 2.26Ghz 8-core machine at times. From a productivity standpoint, I don't get how people can claim that the HTML5 is a superior machine.

      HTML5 addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a HTML5 over other faster, cheaper, more stable systems.

      --
      Unicode in Slashdot
  13. Like just about everything HTML5... by HamSammy · · Score: 1

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

    1. Re:Like just about everything HTML5... by Shikaku · · Score: 1

      The language you are looking for is Haskell, or maybe Scheme/Lisp.

      factorial n = product [1..n]

      Is an entire subroutine for factorials, for example.

  14. An actual link by jfengel · · Score: 2

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

    Google Labs

  15. Re:J u i l i a ? by apetrelli · · Score: 2

    Julia would be "Giulia" in Italian. Juilia is plain wrong.

  16. It performs awesomely by trollertron3000 · · Score: 1

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

    --
    Tiger Blooded Bi-Winning Machine
  17. How is that new!? by Arty2 · · Score: 1

    Just Google it, there are various years old implementations! http://blog.nihilogic.dk/2008/10/23-pretty-javascript-fractals.html

    1. Re:How is that new!? by slim · · Score: 1

      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.

  18. This takes me back... by fuzzyfuzzyfungus · · Score: 1

    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...

    1. Re:This takes me back... by slim · · Score: 2

      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.

    2. Re:This takes me back... by Fnkmaster · · Score: 4, Insightful

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

    3. Re:This takes me back... by aztracker1 · · Score: 1

      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.

      --
      Michael J. Ryan - tracker1.info
    4. Re:This takes me back... by Xtifr · · Score: 1

      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. A boggling 762 bytes of PS.

  19. Re:FAIL by Chrisq · · Score: 1

    Thank god for silverlight, this html5/javascript shit runs like crap.

    Maybe its time to upgrade from IE6. Seriously it runs well in Firefox and Chrome

  20. Slow by Timmmm · · Score: 1

    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 computer using Chrome.

    1. Re:Slow by Rizimar · · Score: 1

      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 standards, the developers will want to make sure that their browsers run as quickly as possible on most machines to compete with one another, so I'm optimistic.

  21. Cool. Crashed Firefox by Bigbutt · · Score: 1

    Excellent demo though :)

    [John]

    --
    Shit better not happen!
  22. Re:Julia? by jgagnon · · Score: 1

    The boobs are at zoom level 450 or so.

    --
    Remember to maintain your supply of /facepalm oil to prevent chafing.
  23. Doh, IE8 Fail by stewbacca · · Score: 1

    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.

    1. Re:Doh, IE8 Fail by Shikaku · · Score: 1

      IE8

      Well there's your problem, good sir.

  24. fully interactive what viewer? by andrewagill · · Score: 1

    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.

  25. Re:Processor use by warrior · · Score: 1

    Exactly. This is why the "application" is a bad idea. I understand the goal of moving "heavy lifting" to the cloud and having "thin" clients. However, it appears that the "thin" client envisioned here is a machine that parses and interprets lots and lots of text. It's so inefficient and wasteful. As a hardware designer, we keep making mobile devices more powerful and energy efficient all so lazy programmers can throw steaming piles of crap onto the devices. It's a hack on top of a hack on top of a hack. Some sort of binary protocol where minimal bytes are passed between server and client is needed here.

    --
    Intel transfer the difficult from Hadware to software, for get more power, programmer need more technology. -- chinaitn
  26. Julia by Stooshie · · Score: 1

    It only goes to a zoom level of 50. Hmm!

    --
    America, Home of the Brave. ... .and the Squaw.
    1. Re:Julia by Endophage · · Score: 1

      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.

  27. Re:Processor use by warrior · · Score: 1

    Supposed to say HTML "application".

    --
    Intel transfer the difficult from Hadware to software, for get more power, programmer need more technology. -- chinaitn
  28. JavaScript is cool and all but by Broolucks · · Score: 1

    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.

    1. Re:JavaScript is cool and all but by DragonWriter · · Score: 1

      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.

  29. I found the bottom by itamblyn · · Score: 1

    It doesn't work past about zoom level 48-50. Fractals aren't supposed to have bottoms.

    1. Re:I found the bottom by FrangoAssado · · Score: 1

      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 problem before that because the calculations done probably lose some precision, so even if you can barely tell apart two adjacent pixels, while iterating the function to calculate a pixel's color, you lose enough precision to make the color come out wrong for at least some pixels.

  30. Google == Copycats! by BeforeCoffee · · Score: 1

    Our Real-World HTML5 Benchmark 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.

  31. Re:FAIL by TrancePhreak · · Score: 1

    I disagree. It runs pretty poorly. I use Chrome.

    --

    -]Phreak Out[-
  32. Re:html5 by SanityInAnarchy · · Score: 1

    What's the point of the canvas tag without an API?

    --
    Don't thank God, thank a doctor!
  33. Re:Processor use by SanityInAnarchy · · Score: 1

    So let's see...

    No, the goal isn't moving "heavy lifting" into the cloud. The advantages of a web application are portability and storage on someone else's servers -- exactly the same advantages that Gmail has always had, and Hotmail had before Gmail.

    The goal of pushing what HTML can do is to keep the advantages of the Web, but also bring the advantages of a fat client -- lower bandwidth, less server resources, and clients which use more resources, but also do more with them.

    And the point of text is to make it transparent.

    I don't see "laziness" anywhere -- in fact, as a hardware designer, I somehow doubt you have any idea what it takes to be a really good web developer. It's true, I don't have to worry about manual garbage collection, let alone voltages, heat, and all the other messiness of the hardware world, and I'm grateful that you take care of that. What I do need is a working knowledge of HTML, XML, CSS, JavaScript, HTTP, and all the different browser quirks involved in implementing that, in addition to some basic graphical editing skills, and on the server side I likely need at least one application language (Ruby, Java, .NET, whatever) along with at least one external DSL the database speaks (SQL). In order to synthesize these into a functioning application, I should also be familiar with the principles of REST, I can't really avoid SOAP as much as I'd like to, and I also have to think about OAuth and security in general (some security issues which don't even apply to standalone apps), HTTPS, HTTP Push (web sockets, comet, etc), how browsers handle caching, and random accumulated tricks of the trade, like CSS "sprites", JavaScript minification, better make sure we turn on gzip compression in the webserver...

    This isn't meant to be me whining that my job is so hard, or even that it's necessarily harder than other application platforms -- I like to think it's easier. The point is that people don't make web apps out of "laziness" -- if laziness was truly a factor, I'd make a commandline app, throw it up as a source tarball, and say "You figure it out," and I will admit to doing that when I can't justify putting the effort in to making it usable.

    No, the reason I'd make a web app is that I want something people can just use by typing a URL from any computer with a decent browser, without worrying about installing something, without needing to manage keeping their data backed up and synced across computers, and without forcing me to support some OSes and platforms and abandon others.

    As for "inefficient and wasteful", sure, there's room for improvement, but have you done an honest comparison between modern JavaScript engines and other VMs? Or are you seriously suggesting that all apps, especially mobile apps, should be written in a language where buffer overruns are still a very real possibility? Because I'll take a little reduced battery life in exchange for stability, and especially from the improved battery life by avoiding some malware.

    --
    Don't thank God, thank a doctor!
  34. Re:Processor use by SanityInAnarchy · · Score: 1

    Do you have a comparable Flash fractal viewer that performs better?

    --
    Don't thank God, thank a doctor!
  35. Re:Processor use by Zappy · · Score: 1

    Well this is progress, this one manages to max-out my quadcore machine AND be slower than 'fractint' was on my "turbo-XT" :-)

  36. Re:Limited to 3 cores? by SanityInAnarchy · · Score: 1

    Chrome seemed to be running at least five or six independent processes. I only have two cores to test it with, though...

    Also, while I doubt it has much of an effect, keep in mind that all major Windows browsers are 32-bit right now, mostly because Flash is 32-bit, which means the browsers are 32-bit, which means Silverlight is 32-bit, which means the browsers are 32-bit... My Chrome is 64-bit, but it can run a 32-bit Flash. Since this is native JS, it'll actually run in 64-bit mode.

    --
    Don't thank God, thank a doctor!
  37. Re:Processor use by imsabbel · · Score: 1

    First hit when googling "Flash Fractal Viewer"

    http://www.felinesoft.com/blog/index.php/2010/10/mandelbrot-fractal-viewer-in-flash-actionscript-3/
    for me faster by about a factor of 3, plus MUCH smoother even when only using a single core.

    --
    HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
  38. For a similar fractal-browsing experience... by zing22 · · Score: 1

    Go here: http://mandelbrot.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!

  39. Runs at a maximum of 50Mflops by loufoque · · Score: 1

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

  40. Re:Processor use by SanityInAnarchy · · Score: 1

    When I set it to the same resolution, I got similar results. The only real disadvantage of the Google viewer was the fact that it was burning both cores.

    I noticed a few other things, also -- the Google viewer was much, much easier to play with. I could drag it around (like Google Maps), I didn't have to wait for it to finish rendering before I could zoom further, it seemed to render in chunks. The Flash viewer was eventually faster once I got deep enough, but before then, it was pretty comparable, except it would zoom first, then start rendering, and become entirely unusable during the entire rendering process.

    That doesn't tell me Flash is faster than JavaScript, especially when ActionScript's Tamarin engine isn't terribly different than modern JavaScript engines (and is capable of running JavaScript also). Instead, what it tells me is that these are very different implementations with different characteristics, which makes comparison difficult.

    --
    Don't thank God, thank a doctor!
  41. Re:Limited to 3 cores? by joemck · · Score: 1

    Chrome used 5 cores on my 8-core Mac Pro (early 2008 model). I had 5 "Google Chrome Worker" tasks running.

    Still not "as many cores as you can give it"...

  42. Browser performance benchmark? by McNihil · · Score: 1

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

    1. Re:Browser performance benchmark? by slamden · · Score: 1

      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.

  43. Progress by sakdoctor · · Score: 1

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

    1. Re:Progress by jedwidz · · Score: 1

      I doubt that, but feel free to back up that claim. Custom chip graphics capabilities on the Amiga were basically limited to tweaking display parameters per-scanline (resolution, palette), block copies, and line drawing (maybe fills too, I'd have to look it up).

    2. Re:Progress by commodore64_love · · Score: 1

      >>>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.)

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    3. Re:Progress by commodore64_love · · Score: 1

      Well..... you're wrong. The GPU and Sound PU could do DMA transfers in order to execute graphics-related code - independent of the 68000. The Amiga was designed that way because it was originally intended to be a games console, and prioritized graphics/sound coprocessing ability.

      Note that the 68000-based Sega Genesis has similar capability with its GPU and SPU operating independently of then cpu.

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
  44. What? by Trogre · · Score: 3, Insightful

    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.

    --
    "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife