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

129 comments

  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: 0

      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.

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

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

      Julia's got a great set allright.

      --
      Huh?
    8. 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. J u i l i a ? by Anonymous Coward · · Score: 0

    I thought it was Julia :)

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

      Maybe some alternative Italian spelling?

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

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

  4. 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 Anonymous Coward · · Score: 0

      The obvious typo in the summary title is probably copied from the obvious typo in the URL in the summary: http://www.i-programmer.info/news/81-web-general/1947-juilia-meets-html5.html

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

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

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

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

    4. Re:Who? by Anonymous Coward · · Score: 0

      He has a point though. It took far fewer people to create that web page than it took to create the iPhone. It would be nice if it said "A, B, and C at Google created..." rather than vaguely attributing it to the entire company.

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

  7. And? by Snaller · · Score: 0

    And ? So what.

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

    --
    If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
  8. Processor use by Anonymous Coward · · Score: 0

    And I thought Flash used a lot of processor time!

    1. 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
    2. 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
    3. 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!
    4. 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!
    5. 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" :-)

    6. 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?
    7. 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!
  9. Re:html5 by MosX · · Score: 5, Informative

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

  10. 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 Anonymous Coward · · Score: 0

      Wow, so this is the future, huh? Slow, CPU-intensive applications that can now do what my TI86 calculator could do back in 2000. Awesome!

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

    7. 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?
    8. Re:Why is this surprising? by Anonymous Coward · · Score: 0

      a simple doom-like demo in javascript

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

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

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

    12. 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
    13. Re:Why is this surprising? by Anonymous Coward · · Score: 0

      2.3GFlops here. Maybe you need to stop scavenging for your computer parts.

    14. Re:Why is this surprising? by Anonymous Coward · · Score: 0

      This Web implementation using ANSI C *scripts* is much faster (real-time):

      Output:
      http://dsec.com/csp_fractal.gif

      Source code:
      http://dsec.com/source/fractal.c.txt

      Tool:
      http://dsec.com/en_developers.html

      And it works nicely with (or without) HTML5.

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

    16. Re:Why is this surprising? by Anonymous Coward · · Score: 0

      I tried it in Firefox and it was quite disappointing. So I tried Chrome and it was more than ten times faster. And I guess that's the point: to show just how fast Chrome is. Speed isn't everything however. I'll stick with Firefox + NoScript + RequestPolicy.

  11. 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
  12. 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
  13. Wow by Executive+Override · · Score: 1

    Almost as slow as the new slashdot interface!

  14. Julia? by Anonymous Coward · · Score: 0

    Boobs?

    1. 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.
  15. 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 Anonymous Coward · · Score: 0

      Points taken.

      FYI browser is firefox 3.6.13

      IIRC my algorithm upped the escape criterion depending on the depth of zoom you were set at and allowed the user to adjust it sort of in real time.

      Obviously it only calculated what was being looked at.

      It remembered what was calculated before so when you zoomed in you had a feint preview of what you were going to get.

      I forgot to mention, it was programmed in the Basic Interpreter that was included in the ROM of the machine.

      It sounds more complicated than it was.

    3. 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."
    4. 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!
    5. 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....

    6. 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
  16. Like just about everything HTML5... by HamSammy · · Score: 1

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

    1. Re:Like just about everything HTML5... by Anonymous Coward · · Score: 0

      It IS more -- more complicated than it should be, that is.

      I guess I'm just being a crabby old-timer, but I really expected that after 25+ years the standards and languages used today would be more easy to use and powerful enough (not in terms of Turing-completeness, but in terms of semantic content) that a few lines would accomplish what once took 10 or 100 or 1000 lines in earlier languages.

      The code just seems to large and verbose for what it does. Perhaps that's just a side-effect of the OO nature of JS. It still bugs me. /Get off my lawn!

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

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

  18. 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
    1. Re:It performs awesomely by Anonymous Coward · · Score: 0

      Well said.

      Who was it that mentioned recently that Google think in a box too -- the browser?

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

  20. Wow by Anonymous Coward · · Score: 0

    They render pixels on screen according to some mathematical equation. Stop the presses, nobody has done this before. Pretty underwhelming coming from Google.
    Microsoft's IE9 HTML5 demos are far more impressive. Actually viewed this on Chrome and it was quite slow, but Chrome is slow compared to most new generation browsers including IE9 when rendering HTML5.

  21. HTML5? by Anonymous Coward · · Score: 0

    From Google? So it's some sort of new-fangled wrapper around Flash?

  22. FAIL by Anonymous Coward · · Score: 0

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

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

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

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

      --

      -]Phreak Out[-
  23. 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.

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

    2. Re:Slow by Anonymous Coward · · Score: 0

      I concur. The performance of JS is still much lower than that Flash (with Silverlight being at the top performance-wise). Granted, that gap will get smaller and it is not all that important for most use-cases HTML5 will be used for.

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

    Excellent demo though :)

    [John]

    --
    Shit better not happen!
    1. Re:Cool. Crashed Firefox by Anonymous Coward · · Score: 0

      Same.

      Minefield Firefox 4.0b10pre(2011-01-20) on 64bit Ubuntu.

      Zoomed in a few times, pushed it a little harder, and down it went. But I can't criticize a beta for not being perfect.

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

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

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

  29. A similar one by Anonymous Coward · · Score: 0

    Here's a similar one: http://blogbybubble.blogspot.com

  30. A similar one by Anonymous Coward · · Score: 0

    There's a similar one at http://blogbybubble.blogspot.com/

  31. SSE and GPU (CUDA) implementation... 210 fps by Anonymous Coward · · Score: 0

    Native languages for CPUs/GPUS... much better at this:

    SSE and GPU (CUDA) implementation... 210 fps at 1024x768

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

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

  34. Limited to 3 cores? by Anonymous Coward · · Score: 0

    I am on a 6 core AMD Phenom II machine and it seems to be limited to only using 3 cores.

    Don't see any ways of increasing the number of cores it can use. Maybe thats a hard limit in that script I guess (no, I have not checked the source).

    FF 3.6.13 running on Win 7 Ult 64bits / 8 GB Ram.

    1. 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!
    2. 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"...

  35. HTML5 Throttling by Anonymous Coward · · Score: 0

    This single core 512MB RAM laptop was choking at 100% on the demo. I immediately thought of Flash. With HTML5, WHERE do we go to in the process managers after the fact to reprioritize? Flash plugins are exposed as a separate process in Firefox. In Opera and IE, it's impossible to micromanage the slow / runaway flash work directly as you only find the whole opera.exe or iexplorer.exe. Chrome has the most separation into multiple processes, though not perfect, and you can guess and shepperd the hungry one individually by percent CPU usage.

      Non-IE HTML5-capable browsers are already at 50% browser share. Since you mentioned underpowered laptops flops-wise, we should remember that it won't be long before clandestine ad-servers start experimenting with the penetration of "dual-stack" ads over our flash blocking tools (for those too squeamish to enable No-script on computers they share with the incompetent and uninformed.) I am concerned that just like we can't throttle JS processor usage separately for, say, slashdot browsing, then ad-makers will slip through our unguarded doors till browsers give us more direct control over impending plugin-less CPU hogging.

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

  37. Re:html5 by SanityInAnarchy · · Score: 1

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

    --
    Don't thank God, thank a doctor!
  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. HTML5 by Anonymous Coward · · Score: 0

    "not a plug-in in sight"

    Submitter needs to check out the following 7 games/gadgets.
    Then (s)he understands that nowadays there is a _lot_ more possible without plug-ins than just checking out fractals.

    TankWorld
    Google Body (yes, also from Google)
    Crystal Galaxy
    Biolab Disaster
    WordSquared
    Canvas Cycle
    Freeciv.net

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

  42. 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 commodore64_love · · Score: 0

      That's because most of Amiga Fractal work 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.

      --
      "I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
    2. 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).

    3. Re:Progress by commodore6502 · · Score: 0

      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.

      --
      Information wants to be expensive AND wants to be free. So you have Value vs. Cheap distribution fighting each other.
    4. 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
    5. 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
    6. Re:Progress by Anonymous Coward · · Score: 0

      Well..... you're wrong.

      Then where's the citation?

      You don't have one? Well then, you are lying.

    7. Re:Progress by Anonymous Coward · · Score: 0

      So when called out on the fact that you have provided no citation, instead of manning up and doing so like you demand of others, you just post copypasta.

      I'll give you the benefit of the doubt and presume that you are not trolling, but I'd love to know how you can call this anything but a troll post.

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