Fast software rasteriser in JavaScript?
category: code [glöplog]
torus: interesting! 12k would have been plenty for storing some "shaders" :)
I'm currently tinkering with the STM32F4xx platform -- quite low-end (128+12+64 kbytes SRAM / ~80 MBytes/sec fill-rate)
but a lot of fun since there's no OS / API bloat. some sceners have made a demo for it recently (bit-banging VGA out via a simple resistor ladder ;))
you should check it out if you have not, yet.
I also have to dust off my Pandaboard since ImgTec finally released a GLES driver this week that does not need X11..
but before anyone starts complaining, back to the original topic!
I'm still hoping to live to see the day when there's a WWW standard for a browser VM suitable for C (and other languages) and this kind of "idiocy" stops.
The current JS engines may be well coded but JS simply was not designed for this task.
Maybe I'm missing something and people are already working on such a VM, in that case, please educate me.
I'm currently tinkering with the STM32F4xx platform -- quite low-end (128+12+64 kbytes SRAM / ~80 MBytes/sec fill-rate)
but a lot of fun since there's no OS / API bloat. some sceners have made a demo for it recently (bit-banging VGA out via a simple resistor ladder ;))
you should check it out if you have not, yet.
I also have to dust off my Pandaboard since ImgTec finally released a GLES driver this week that does not need X11..
but before anyone starts complaining, back to the original topic!
Quote:
They take open source C/C++ projects, and cross compile them to JavaScript.
I'm still hoping to live to see the day when there's a WWW standard for a browser VM suitable for C (and other languages) and this kind of "idiocy" stops.
The current JS engines may be well coded but JS simply was not designed for this task.
Maybe I'm missing something and people are already working on such a VM, in that case, please educate me.
yep, that's nice tech (but I'm still waiting for pnacl)
the other browser vendors don't seem to like it / refuse to implement it, though.
hopefully they change their minds or at least develop something similar in cooperation with Google.
the other browser vendors don't seem to like it / refuse to implement it, though.
hopefully they change their minds or at least develop something similar in cooperation with Google.
Quote:
The current JS engines may be well coded but JS simply was not designed for this task.
Well put, well put.
As for NaCl.. yes another browserspecific glorified plugin model. Great, can't wait for every jackass to run his (albeit sandboxed) native code on my box :)
yea we discussed that some time ago :)
It does not necessarily have to be NaCl.
Maybe an ISA with some rather high-level instructions would be a better choice.
(after all, in SW we don't have the chip-size problems the HW guys have)
At least gimme something that is a lot more close to the metal than JS :D
It does not necessarily have to be NaCl.
Maybe an ISA with some rather high-level instructions would be a better choice.
(after all, in SW we don't have the chip-size problems the HW guys have)
At least gimme something that is a lot more close to the metal than JS :D
(last but not least: there's already enough "jackass" JS code around today that makes my browser freeze / causes 100% load / drains the batteries, so that's not a valid argument ;))
(hmm ok, you were aiming for the browserspecific argument, that's valid, of course!)
yeah i remember that discussion :)
maybe i'm a bit old-fashioned by i tend to think that perhaps a browser isn't the right delivery platform for your product if you need it that much closer to the so-called metal.
it's a bit messy now and hopefully things will mature into somewhat standardized and widely carried technologies.
other than that we're veering off course here :)
maybe i'm a bit old-fashioned by i tend to think that perhaps a browser isn't the right delivery platform for your product if you need it that much closer to the so-called metal.
it's a bit messy now and hopefully things will mature into somewhat standardized and widely carried technologies.
other than that we're veering off course here :)
by->but, i'm tired.
NaCl is clearly targetting ChromeOS's future and not the current web anyways.
I'm also quite tired now (14h at work..sigh) and I consider myself old-fashioned, too :)
the whole "re-invent the OS in a browser" trend is rather questionable, anyway.
(i.e. design-wise, security / APIs should be close to / left to the underlying (standardized) OS, IMHO. ideally..)
A fast JIT/low-level runtime is one thing, the more important aspect are the APIs / eco-systems around it..
(plus you're right regarding the "delivery platform" -- IMHO, web apps are good for e.g. office tools and for that
they work just fine. games/demos are a whole different topic, for good reasons)
ah, let's call it a day and let the others return to the original topic.
maybe we look back at discussions like these in ten years from now and have a good laugh. *shrug*
nighty night!
the whole "re-invent the OS in a browser" trend is rather questionable, anyway.
(i.e. design-wise, security / APIs should be close to / left to the underlying (standardized) OS, IMHO. ideally..)
A fast JIT/low-level runtime is one thing, the more important aspect are the APIs / eco-systems around it..
(plus you're right regarding the "delivery platform" -- IMHO, web apps are good for e.g. office tools and for that
they work just fine. games/demos are a whole different topic, for good reasons)
ah, let's call it a day and let the others return to the original topic.
maybe we look back at discussions like these in ten years from now and have a good laugh. *shrug*
nighty night!
considering how the games markets has moved more from consoles to flash / browsers / mobile in the last few years i'd say you console coders might be a tad too clingy to your weapon of choice on this particular debacle, despite the clear reasoning implied.
then again broandband streamed gameplay does somewhat patch both worlds back together again somewhat.
folks are just trying to maximize the juice they can get out of things.
or its just 4am and i should really be sleeping instead of typing on pouet.
then again broandband streamed gameplay does somewhat patch both worlds back together again somewhat.
folks are just trying to maximize the juice they can get out of things.
or its just 4am and i should really be sleeping instead of typing on pouet.
Quote:
on the contrary, if you want to see how well the JS compiler does compared to a C++ compiler, that's the *only* thing that makes sense.
That gives you a comparison between two compilers' respective ability to optimise the same code. How is that interesting? Of course Chrome's JS compiler is going to improve over time, and probably faster than g++ since it can borrow from all the work already done on other compilers, including g++. All compilers should converge on being equally good, basically, it's only a matter of time.
What's relevant is that Javascript and C++ are different languages, and the native environment is different from a virtual machine. The only thing that makes sense is to compare the best Javascript effort to the best C++ (native code) effort, while acknowledging that good Javascript code looks nothing like good C++ code. Even better if you allow inline ASM in the C++ version. Because that actually tells you something about the potential of browser-based applications vs. native applications.
In the end what matters is the shit you do and its impact on others. So pick your technology based on that.
and don't be offended by other's people technological choices.
...as for comparing C++ vs JS, I just wanted to do a 1:1 comparison (having the two doing roughly the same thing), because that tells us something about code generation quality. I think that I've proven that (for this particular case), the code generation of the JS JITs are pretty impressive. Remember, JS has to guarantee a lot more than C++, such as array bounds checks, integer overflow checks, type checks/conversions, etc. Also, g++ -O3 does a whole lot more work than a dynamic JIT can practically do in real time.
Now, it's true that in native code you can do a lot more "clever" things. You can utilize SIMD intrinsics, code directly in assembler, do cache pre-loading, use unions & ugly casts, etc. Obviously you can't do that in JS. You probably could in NaCl (at least some of it), but without trying to start an infected discussion about it, I have my doubts about NaCl. It certainly doesn't feel like a web technology, and in a world of an ever changing CPU architecture landscape (x86, ARM, MIPS, PowerPC, 32-bit, 64-bit, new instruction sets, etc), it doesn't make much sense to statically compile web apps once and hope that it runs everywhere for many years to come (support for MS-DOS programs in Windows, anyone? or how about emulating PowerPC on Intel Mac OS X machines?).
With that said, I still think that JS is capable enough for doing some heavy lifting. You will not get optimal performance - for that you should use native programs (e.g. if we're talking maximum realism 3D rendering & physics or some business critical time-is-money data processing). However the JS platform gives you some very clear advantages that you can't beat with native apps. Most notably instant accessibility and super-natural integration with the oh-so-popular internets.
That at least inspires me to explore the limits of JS, and hey - isn't that what demo programming is all about? Exploring the limits of a given technology? ;)
Now, it's true that in native code you can do a lot more "clever" things. You can utilize SIMD intrinsics, code directly in assembler, do cache pre-loading, use unions & ugly casts, etc. Obviously you can't do that in JS. You probably could in NaCl (at least some of it), but without trying to start an infected discussion about it, I have my doubts about NaCl. It certainly doesn't feel like a web technology, and in a world of an ever changing CPU architecture landscape (x86, ARM, MIPS, PowerPC, 32-bit, 64-bit, new instruction sets, etc), it doesn't make much sense to statically compile web apps once and hope that it runs everywhere for many years to come (support for MS-DOS programs in Windows, anyone? or how about emulating PowerPC on Intel Mac OS X machines?).
With that said, I still think that JS is capable enough for doing some heavy lifting. You will not get optimal performance - for that you should use native programs (e.g. if we're talking maximum realism 3D rendering & physics or some business critical time-is-money data processing). However the JS platform gives you some very clear advantages that you can't beat with native apps. Most notably instant accessibility and super-natural integration with the oh-so-popular internets.
That at least inspires me to explore the limits of JS, and hey - isn't that what demo programming is all about? Exploring the limits of a given technology? ;)
Quote:
and don't be offended by other's people technological choices.
This should be on a T-shirt. :) Even if you are offended (as silly as that is), please make sure that your arguments are not based on hear-say from 1995.
Quote:
isn't that what demo programming is all about? Exploring the limits of a given technology? ;)
Some "demo programming" is about that. I'd rather go with the more general idea of "self-expression/doing interesting shit".
Quote:
I'd rather go with the more general idea of "self-expression/doing interesting shit".
Sure - the art/creativity part is perhaps one of the most important aspects, but expression you can do in an edited YouTube video - what really makes the shit interesting, IMO, is the technology behind it (and it's limitations). If not, we wouldn't see any products on 8-bit platforms, all the 64k/4k/1k/... products, etc.
Sure, context is part of it. As it has been pointed out elsewhere, usually (media) art is divorced from its means of creation, while demos are clearly different in that regard. I'm just saying that _I_ don't care about breaking any tech sound barriers with my _own_ stuff, but I still enjoy tech stunt stuff that does just that. :)
rumor has it this thread was originally about js tri fillers, so: https://gist.github.com/2486101 updated.
raster3_ryg7.html now with just semi-braindead instead of totally braindead outer loop traversal! (note: in this code, with the fast block rejects, it's really all about the outer loop). at 1000 tris/frame, this is roughly 2x faster than the variant in raster3_ryg6.html.
and all this without using any javascript sse intrinsics! oh wait.
raster3_ryg7.html now with just semi-braindead instead of totally braindead outer loop traversal! (note: in this code, with the fast block rejects, it's really all about the outer loop). at 1000 tris/frame, this is roughly 2x faster than the variant in raster3_ryg6.html.
and all this without using any javascript sse intrinsics! oh wait.
Hmmm... Wonder if it's possible to use an ArrayBufferView to do 32-bit array accesses instead of 8-bit accesses (for faster pixel-writing). Not sure if it's possible to use it for CanvasPixelArray though.
The stupid CanvasPixelArray is dead. It's been replaced by a Uint8ClampedArray which should be usable as an ArrayBufferView.
Quote:
Now, it's true that in native code you can do a lot more "clever" things. You can utilize SIMD intrinsics, code directly in assembler, do cache pre-loading, use unions & ugly casts, etc.
Writing properly balanced code that respects the hardware it runs on is clever, not "clever".
Quote:
raster3_ryg7.html now with just semi-braindead instead of totally braindead outer loop traversal! (note: in this code, with the fast block rejects, it's really all about the outer loop). at 1000 tris/frame, this is roughly 2x faster than the variant in raster3_ryg6.html.
Clever!
My computer is dumb slow, so I cannot test this, but I though: why isn't the drawPixel function inlined into the rectangle function? It's not like it's the most expensive thing, but there's no reason to calculate the offset for every pixel drawn!
Something like this, untested:
Something like this, untested:
Code:
function drawRectangle( x1, y1, x2, y2, color ) {
var r = color >> 16 & 255;
var g = color >> 8 & 255;
var b = color & 255;
var xmin = Math.min( x1, x2 ) >> 0;
var xmax = Math.max( x1, x2 ) >> 0;
var ymin = Math.min( y1, y2 ) >> 0;
var ymax = Math.max( y1, y2 ) >> 0;
for ( var y = ymin; y < ymax; y ++ ) {
var offset = ( xmin + y * canvasWidth ) * 4;
for ( var x = xmin; x < xmax; x ++ ) {
if ( data[ offset + 3 ] ) return;
data[ offset ] = r;
data[ offset + 1 ] = g;
data[ offset + 2 ] = b;
data[ offset + 3 ] = 255;
offset++;
}
}
}
How a about a traditional span rasterizer (i.e. calculate start/stop x for each line) with a similar "Z buffer" block structure as in the half-space version? I.e. skip 8 pixels ahead if the block is already filled.
Feels like you'd get rid of the (cx1 | cx2 | cx3) >= 0 comparison for the edge cases, since you already know the start/stop coordinates.
Isn't one of the major advantages of the half-space solution that it's easy to SIMD-optimize it?
Feels like you'd get rid of the (cx1 | cx2 | cx3) >= 0 comparison for the edge cases, since you already know the start/stop coordinates.
Isn't one of the major advantages of the half-space solution that it's easy to SIMD-optimize it?