Graphics cards should be able to mix indexed 256-color palette modes with 32-bit color modes, as a texture or 2-d overlay or something. That way you could do cool tricks that involved changing the palette without having to change your system's screen mode.
Even cooler, allow this in JavaScript.
Tuesday, August 24, 2010
Tuesday, August 17, 2010
Wouldn't it be great if I could, say, for example, listen to music playing Winamp visualizations and stream it to one of my blogs as a dynamically changing background?
As the communication channels get faster, how will IT technology adapt to take advantage of it?
NativeClient (one of Gooogle's pet projects) takes native code and rigorously proves using proof theory that it can't commit any kind of violation or infraction under any circumstances, so it's safe. That allows websites to send native code to the client for execution, which is probably dozens of times faster than JavaScript with JIT. The drawback is, of course, that any CPU architecture that isn't supported - well - won't be supported. But x86 isn't the only architecture they're pursuing, and as of now, Windows, Linux, FreeBSD and Mac computers all use x86 anyway. Mobile devices don't, but some of them don't even show Flash..(>:)).. and ARM is probably one of the architectures they're pursuing anyway.
With NativeClient I could program my *own* visualizations to be running as a page background, all the time.
But let's say I wanted to stream it? HTML 5 might be able to handle that, with sufficient speed. But of course if it's a public blog site, the blog site must allow that kind of connectivity for me to stream it. How generalized would this ability be? Quickest solution: JavaScript can send requests to domains other than the document's origin. XmlRpcRequests aren't that good at streaming, though; you'd normally have to use a hidden frame for that.
And let's say 5 people read my blog simultaneously? Would I want to have to waste bandwidth streaming the same visual to all 5 of them? Why couldn't I just use multicast? But now we have to allow the consumer to use multicast, and we have to allow JavaScript to tap in..
I imagine new APIs usable by blogger sites or any other site that would make such communications (and much more) possible, but what exactly will the APIs contain?
Basically we're talking about shifting into a more dynamic and freely flowing information age. I have mixed feelings about that in general, but it's -going- to happen, so the sooner we get to thinking about how we're going to do it *right*, the better.
As the communication channels get faster, how will IT technology adapt to take advantage of it?
NativeClient (one of Gooogle's pet projects) takes native code and rigorously proves using proof theory that it can't commit any kind of violation or infraction under any circumstances, so it's safe. That allows websites to send native code to the client for execution, which is probably dozens of times faster than JavaScript with JIT. The drawback is, of course, that any CPU architecture that isn't supported - well - won't be supported. But x86 isn't the only architecture they're pursuing, and as of now, Windows, Linux, FreeBSD and Mac computers all use x86 anyway. Mobile devices don't, but some of them don't even show Flash..(>:)).. and ARM is probably one of the architectures they're pursuing anyway.
With NativeClient I could program my *own* visualizations to be running as a page background, all the time.
But let's say I wanted to stream it? HTML 5 might be able to handle that, with sufficient speed. But of course if it's a public blog site, the blog site must allow that kind of connectivity for me to stream it. How generalized would this ability be? Quickest solution: JavaScript can send requests to domains other than the document's origin. XmlRpcRequests aren't that good at streaming, though; you'd normally have to use a hidden frame for that.
And let's say 5 people read my blog simultaneously? Would I want to have to waste bandwidth streaming the same visual to all 5 of them? Why couldn't I just use multicast? But now we have to allow the consumer to use multicast, and we have to allow JavaScript to tap in..
I imagine new APIs usable by blogger sites or any other site that would make such communications (and much more) possible, but what exactly will the APIs contain?
Basically we're talking about shifting into a more dynamic and freely flowing information age. I have mixed feelings about that in general, but it's -going- to happen, so the sooner we get to thinking about how we're going to do it *right*, the better.
Monday, August 16, 2010
inhahe: i just thought of a good prank to pull on telemarketers
inhahe: first time one calls, answer, don't speak, record their reaction
theteofscuba: they don't even use the do not call registry any more
inhahe: second time one calls, play back the recording of the first one
inhahe: and record their response
theteofscuba: we get telemarketers calling daily
inhahe: third time one calls, play back the second telemarkter's response and record their response
inhahe: etc.
theteofscuba: hmm
inhahe: first time one calls, answer, don't speak, record their reaction
theteofscuba: they don't even use the do not call registry any more
inhahe: second time one calls, play back the recording of the first one
inhahe: and record their response
theteofscuba: we get telemarketers calling daily
inhahe: third time one calls, play back the second telemarkter's response and record their response
inhahe: etc.
theteofscuba: hmm
Subscribe to:
Posts (Atom)
