rendering graphics with node?
Tom Carden
API for node and wondered if anyone has experimented with something
similar yet?
I added a note on the GSOC ideas page: http://wiki.github.com/ry/node/google-summer-of-code-2010-ideas
and I'd be happy to mentor such a project from the point of view of a
consumer of graphics APIs. However I wouldn't be much use on the
implementation side of things.
I imagine that the canvas API itself could be iterated on in pure js,
and the main big task would be exposing bindings to a suitable low-
level library such as Cairo, Skia or AGG.
I also imagine that optimising and structuring such a framework for a
non-blocking event driven environment could be an interesting
challenge in its own way. There's only so much you can draw before the
next event comes along :)
Interested to hear your thoughts,
Tom.
Schell
--
Schell Scivally
sch...@efnx.com (efsub...@gmail.com)
http://blog.efnx.com
Ivan Boldyrev
> I also imagine that optimising and structuring such a framework for a
> non-blocking event driven environment could be an interesting
> challenge in its own way. There's only so much you can draw before the
> next event comes along :)
Then drawing should be performed on another thread, otherwise event
interface is useless, as drawing is usually memory- and CPU-bound, not
I/O-bound.
--
Ivan Boldyrev
Ryan Dahl
Yes - which makes it a rather difficult project.
Felix Geisendörfer
existing infrastructure for non-blocking graphics one could build on.
So given the complexity of rolling a new graphics library from
scratch, I'd say something threaded will be the way to go for this.
-- fg
On Mar 3, 5:02 am, Ryan Dahl <coldredle...@gmail.com> wrote:
> On Tue, Mar 2, 2010 at 7:55 PM, Ivan Boldyrev <lisp...@gmail.com> wrote:
Blaine Cook
isn't non-blocking, nor are (correct me if I'm wrong!) ActionScript
graphics. I could be wrong, but my understanding is that most
Javascript-based graphics (and most long-running graphics in general)
draw on a timer, something like setTimeout(redrawScene(), 20), which
would handily yield control to node and prevent an infinitely blocking
case.
I know very little about graphics, but I like the idea of node.js
being a fast & scalable Javascript graphics engine, and thought it
might be worthwhile to emphasize that the solution might be much
simpler than running things in a thread.
b.
2010/3/3 Felix Geisendörfer <fe...@debuggable.com>:
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>
Ryan Dahl
> Is it necessary for graphics to be non-blocking? Canvas in the browser
> isn't non-blocking, nor are (correct me if I'm wrong!) ActionScript
> graphics. I could be wrong, but my understanding is that most
> Javascript-based graphics (and most long-running graphics in general)
> draw on a timer, something like setTimeout(redrawScene(), 20), which
> would handily yield control to node and prevent an infinitely blocking
> case.
>
> I know very little about graphics, but I like the idea of node.js
> being a fast & scalable Javascript graphics engine, and thought it
> might be worthwhile to emphasize that the solution might be much
> simpler than running things in a thread.
The concern is that the graphics I/O could slow down network I/O. It
would be nice to have them on different threads. A single thread
solution would work - it probably just wouldn't be optimal.
christkv
accept some sort of threading support in node.js ?
Christian
Ryan Dahl
> Yeah it needs to be multithreaded which begs the question if Ryan will
> accept some sort of threading support in node.js ?
What would that mean? There is threading support in the form of libeio
- but that is inappropriate for such a graphics thread.
Matthew Ranney
The concern is that the graphics I/O could slow down network I/O. It
would be nice to have them on different threads. A single thread
solution would work - it probably just wouldn't be optimal
christkv
new Thread(function() { dosomething }) using system threads and not
processes. Posix Threads or something I guess.
Christian
On Mar 3, 6:17 pm, Matthew Ranney <m...@ranney.com> wrote:
Jim R. Wilson
operations in a separate forked process?
-- Jim R. Wilson (jimbojw)
Ryan Dahl
> I mean more in the style of
>
> new Thread(function() { dosomething }) using system threads and not
> processes. Posix Threads or something I guess.
Javascript doesn't have threads and the entire point of this project
is to eliminate that sort of programming. So, no.
On Wed, Mar 3, 2010 at 9:23 AM, Jim R. Wilson <wilson...@gmail.com> wrote:
> Speaking of processes, would it be possible to perform graphics
> operations in a separate forked process?
Yes, that should be possible. We could just tell people to not put
graphics and networking in the same process - of course that means
they'll need to do a lot of IPC - but maybe that's okay. My thought
was that the library could do the IPC for the user (by communicating
commands to the internal graphics thread).
christkv
Object.seal( obj )
Object.freeze( obj )
are not implemented or one could have Threading without the pain using
a erlang style approach to threading with immutable objects. Most of
the classic pain with threading is the shared state right.
Just my 5 cents.
Christian
On Mar 3, 6:28 pm, Ryan Dahl <coldredle...@gmail.com> wrote:
> On Wed, Mar 3, 2010 at 9:20 AM, christkv <chris...@gmail.com> wrote:
> > I mean more in the style of
>
> > new Thread(function() { dosomething }) using system threads and not
> > processes. Posix Threads or something I guess.
>
> Javascript doesn't have threads and the entire point of this project
> is to eliminate that sort of programming. So, no.
>
Blaine Cook
> The concern is that the graphics I/O could slow down network I/O. It
> would be nice to have them on different threads. A single thread
> solution would work - it probably just wouldn't be optimal.
Ahh, okay - I was imagining that the sort of graphics work that might
target node.js would be file- or network-bound image generation. More
OpenStreetMap tile generation or "graphs and charts" than desktop /
gaming 30 fps no-more-no-less graphics; places where web workers or
just multiple processes would be more than adequate if processing
capacity were a problem.
b.
Karl Guertin
list, but there's a set of GD bindings for people who want something
now:
http://github.com/taggon/node-gd
Haven't tested it, just noticed it when it showed up on the modules page.
Tom Carden
Rasterisation might be the only asynchronous work needed (done in
native threaded code) . This is analagous to how a browser does canvas
or svg rendering off in its own thread, away from javascript. Or how
Flash rendering works, where once you've chewed through a bunch of
drawing calls in actionscript, the Flash Player does its best to
rasterise those and blit them to screen in the remaining frame time
(usually a few 10s of milliseconds). So a scene description would be
built in js and everything else would be handled elsewhere.
Mentioning OpenStreetMap and graphs and charts it's almost like you
know what I want to do already ;)
Tom.
