Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

129 comments

html5 (-1)

Anonymous Coward | more than 3 years ago | (#35067876)

Just because they've not put in a doctype (valid html5) doesn't make this some sort of html5 application.

It's a javascript application.

Re:html5 (5, Informative)

MosX (773406) | more than 3 years ago | (#35067936)

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

Re:html5 (-1)

Anonymous Coward | more than 3 years ago | (#35068530)

The canvas tag may be, but the canvas API is not.

This is not a proper use of the term HTML5.

Re:html5 (1)

SanityInAnarchy (655584) | more than 3 years ago | (#35070424)

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

The article is on a webpage. (2, Informative)

Anonymous Coward | more than 3 years ago | (#35067880)

So why not hyperlink "Julia sets" to something telling us wtf a Julia set is [wikipedia.org] ?

Re:The article is on a webpage. (3, Informative)

Kozar_The_Malignant (738483) | more than 3 years ago | (#35068322)

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

Re:The article is on a webpage. (2)

History's Coming To (1059484) | more than 3 years ago | (#35068354)

And how to spell it in a headline.

Re:The article is on a webpage. (-1)

Anonymous Coward | more than 3 years ago | (#35068390)

No, "dorks" know what a Julia set is. Fractals are great when you're showing off to your LARP buddies how much better the screen savers in Slackware Linux are than the flying toasters in Windows 3.1. "Nerds" are studying mathematics (among other things) that actually matters.

Re:The article is on a webpage. (1)

Nadaka (224565) | more than 3 years ago | (#35068508)

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

Re:The article is on a webpage. (0)

Anonymous Coward | more than 3 years ago | (#35068598)

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.

Re:The article is on a webpage. (1)

Anonymous Coward | more than 3 years ago | (#35069232)

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

Re:The article is on a webpage. (1)

wideBlueSkies (618979) | more than 3 years ago | (#35069804)

Julia's got a great set allright.

pah! (1)

MancunianMaskMan (701642) | more than 3 years ago | (#35067882)

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]

Re:pah! (1)

foobsr (693224) | more than 3 years ago | (#35068452)

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.

J u i l i a ? (0)

Anonymous Coward | more than 3 years ago | (#35067888)

I thought it was Julia :)

Re:J u i l i a ? (1)

jdpars (1480913) | more than 3 years ago | (#35067920)

Maybe some alternative Italian spelling?

Re:J u i l i a ? (2)

apetrelli (1308945) | more than 3 years ago | (#35068092)

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

Link missing from summary. (3, Insightful)

Kagura (843695) | more than 3 years ago | (#35067896)

Re:Link missing from summary. Fixed (1)

Kagura (843695) | more than 3 years ago | (#35067918)

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

Re:Link missing from summary. (0)

Anonymous Coward | more than 3 years ago | (#35067932)

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

Re:Link missing from summary. (1)

mikejuk (1801200) | more than 3 years ago | (#35068878)

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.

Who? (2)

DeathSquid (937219) | more than 3 years ago | (#35067904)

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

Re:Who? (-1)

Anonymous Coward | more than 3 years ago | (#35068170)

Read this. [wikipedia.org]

The fact is, this is an example of a corporation that has created something. And if Google finds some way to monetize this creation, well it will be people who are ultimately behind that. I'm sorry that the facts here, and the language used to describe them, don't serve prop up your odd worldview.

Re:Who? (1)

MightyYar (622222) | more than 3 years ago | (#35068438)

Corporations monetize.

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

Re:Who? (1)

afabbro (33948) | more than 3 years ago | (#35068696)

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

Re:Who? (1)

Ksevio (865461) | more than 3 years ago | (#35070770)

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

And? (0)

Snaller (147050) | more than 3 years ago | (#35067926)

And ? So what.

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

Processor use (0)

Anonymous Coward | more than 3 years ago | (#35067930)

And I thought Flash used a lot of processor time!

Re:Processor use (1)

warrior (15708) | more than 3 years ago | (#35068590)

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.

Re:Processor use (1)

warrior (15708) | more than 3 years ago | (#35068710)

Supposed to say HTML "application".

Re:Processor use (1)

SanityInAnarchy (655584) | more than 3 years ago | (#35070704)

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.

Re:Processor use (1)

SanityInAnarchy (655584) | more than 3 years ago | (#35070716)

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

Re:Processor use (1)

Zappy (7013) | more than 3 years ago | (#35070812)

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

Why is this surprising? (2)

slim (1652) | more than 3 years ago | (#35067962)

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

Re:Why is this surprising? (3, Insightful)

jfengel (409917) | more than 3 years ago | (#35068102)

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.

Re:Why is this surprising? (1)

slim (1652) | more than 3 years ago | (#35068250)

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.

Re:Why is this surprising? (0)

Anonymous Coward | more than 3 years ago | (#35069212)

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!

Re:Why is this surprising? (1)

fractalus (322043) | more than 3 years ago | (#35069334)

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.

Re:Why is this surprising? (1)

jfengel (409917) | more than 3 years ago | (#35069692)

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.

Re:Why is this surprising? (0)

Anonymous Coward | more than 3 years ago | (#35070354)

HTML5 Throttling (0)

Anonymous Coward | more than 3 years ago | (#35069460)

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.

Re:Why is this surprising? (1)

imsabbel (611519) | more than 3 years ago | (#35070228)

HTML5, Now only 100 times slower than real applications!

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

Re:Why is this surprising? (2)

DerekLyons (302214) | more than 3 years ago | (#35070408)

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.

Re:Why is this surprising? (2)

Jahava (946858) | more than 3 years ago | (#35068404)

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.

Re:Why is this surprising? (1)

DiegoBravo (324012) | more than 3 years ago | (#35071428)

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

Original link (1)

kiwix (1810960) | more than 3 years ago | (#35067972)

The HTML demo is here. [googlelabs.com]

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

Re:Original link (1)

gid (5195) | more than 3 years ago | (#35068122)

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.

Re:Original link (1)

foobsr (693224) | more than 3 years ago | (#35068544)

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

CC.

Ahhh fractal demos (2, Informative)

commodore64_love (1445365) | more than 3 years ago | (#35067974)

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

Re:Ahhh fractal demos (1)

commodore64_love (1445365) | more than 3 years ago | (#35068066)

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

Re:Ahhh fractal demos (1)

icebraining (1313345) | more than 3 years ago | (#35068186)

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

Re:Ahhh fractal demos (1)

Mr. McGibby (41471) | more than 3 years ago | (#35071232)

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

Wow (1)

Executive Override (605018) | more than 3 years ago | (#35067980)

Almost as slow as the new slashdot interface!

Julia? (0)

Anonymous Coward | more than 3 years ago | (#35067982)

Boobs?

Re:Julia? (1)

jgagnon (1663075) | more than 3 years ago | (#35068442)

The boobs are at zoom level 450 or so.

Gave up waiting (1)

sce7mjm (558058) | more than 3 years ago | (#35068016)

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?

Re:Gave up waiting (1)

BZ (40346) | more than 3 years ago | (#35068388)

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.

Re:Gave up waiting (0)

Anonymous Coward | more than 3 years ago | (#35068732)

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.

Re:Gave up waiting (1)

Rockoon (1252108) | more than 3 years ago | (#35070466)

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.

Re:Gave up waiting (1)

BZ (40346) | more than 3 years ago | (#35070880)

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

Re:Gave up waiting (1)

SanityInAnarchy (655584) | more than 3 years ago | (#35070836)

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.

Like just about everything HTML5... (1)

HamSammy (1716116) | more than 3 years ago | (#35068028)

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

Re:Like just about everything HTML5... (0)

Anonymous Coward | more than 3 years ago | (#35068382)

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!

Re:Like just about everything HTML5... (1)

Shikaku (1129753) | more than 3 years ago | (#35068572)

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.

An actual link (2)

jfengel (409917) | more than 3 years ago | (#35068068)

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

Google Labs [googlelabs.com]

It performs awesomely (1)

trollertron3000 (1940942) | more than 3 years ago | (#35068096)

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

Re:It performs awesomely (0)

Anonymous Coward | more than 3 years ago | (#35068932)

Well said.

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

How is that new!? (1)

Arty2 (1742112) | more than 3 years ago | (#35068108)

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

Re:How is that new!? (1)

slim (1652) | more than 3 years ago | (#35068178)

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.

Wow (0)

Anonymous Coward | more than 3 years ago | (#35068114)

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.

HTML5? (0)

Anonymous Coward | more than 3 years ago | (#35068124)

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

FAIL (0)

Anonymous Coward | more than 3 years ago | (#35068154)

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

Re:FAIL (1)

Chrisq (894406) | more than 3 years ago | (#35068234)

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

Re:FAIL (1)

TrancePhreak (576593) | more than 3 years ago | (#35070238)

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

This takes me back... (1)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#35068190)

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

Re:This takes me back... (2)

slim (1652) | more than 3 years ago | (#35068316)

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.

Re:This takes me back... (4, Insightful)

Fnkmaster (89084) | more than 3 years ago | (#35068574)

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

Re:This takes me back... (1)

aztracker1 (702135) | more than 3 years ago | (#35070444)

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.

Slow (1)

Timmmm (636430) | more than 3 years ago | (#35068254)

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.

Re:Slow (1)

Rizimar (1986164) | more than 3 years ago | (#35068402)

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.

Re:Slow (0)

Anonymous Coward | more than 3 years ago | (#35068968)

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.

Cool. Crashed Firefox (1)

Bigbutt (65939) | more than 3 years ago | (#35068344)

Excellent demo though :)

[John]

Doh, IE8 Fail (1)

stewbacca (1033764) | more than 3 years ago | (#35068466)

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.

Re:Doh, IE8 Fail (1)

Shikaku (1129753) | more than 3 years ago | (#35068584)

IE8

Well there's your problem, good sir.

fully interactive what viewer? (1)

andrewagill (700624) | more than 3 years ago | (#35068536)

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

Julia (1)

Stooshie (993666) | more than 3 years ago | (#35068688)

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

Re:Julia (1)

Endophage (1685212) | more than 3 years ago | (#35068906)

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.

A similar one (0)

Anonymous Coward | more than 3 years ago | (#35068716)

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

A similar one (0)

Anonymous Coward | more than 3 years ago | (#35068856)

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

SSE and GPU (CUDA) implementation... 210 fps (0)

Anonymous Coward | more than 3 years ago | (#35068912)

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

SSE and GPU (CUDA) implementation... 210 fps at 1024x768 [ece.ntua.gr]

JavaScript is cool and all but (1)

Broolucks (1978922) | more than 3 years ago | (#35069138)

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.

Re:JavaScript is cool and all but (1)

DragonWriter (970822) | more than 3 years ago | (#35071028)

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.

I found the bottom (1)

itamblyn (867415) | more than 3 years ago | (#35069206)

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

Limited to 3 cores? (0)

Anonymous Coward | more than 3 years ago | (#35069322)

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.

Re:Limited to 3 cores? (1)

SanityInAnarchy (655584) | more than 3 years ago | (#35070922)

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.

Google == Copycats! (1)

BeforeCoffee (519489) | more than 3 years ago | (#35069716)

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.

For a similar fractal-browsing experience... (1)

zing22 (787912) | more than 3 years ago | (#35071116)

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!

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...