On 4 June 2010 16:26, Juan Vuletich <juan@jvuletich.org> wrote:
Igor Stasenko wrote:
On 2 June 2010 15:16, Juan Vuletich <juan@jvuletich.org> wrote:
Lukas Renggli wrote:
Hi Juan,
This looks really exiting!
How do you get the actual pixels drawn? Is this implemented in Smalltalk? Did you write primitives to do that? Are you using external libraries? How does it compare performance wise with the current rendering?
Lukas
Hi Lukas,
I'm glad you like it. It is all done in Smalltalk. There are no external libraries. In fact, I developed new drawing algorithms that are better than those in Cairo, AGG, etc. So there are no libraries in existence I could call!
The sampling theorem is about 80 years old. It is the base (together with Fourier analysis) of most of the DSP (Digital Signal Processing) field. It is therefore the basis of digital audio and photography. But it seems I am the first one to apply it to 2d rendering! I have been working on this for the last 3 years, after finishing my Ms.Sc. in CS on Image and Signal Processing. I had to establish the theoretical foundations, and come up with new algorithms to draw basic elements using this theory. What you see are the first practical result of all this work.
It is still pure Smalltalk, and therefore, a bit slow. The lion takes 1.8 secs to draw on my 1.6GHz Mac mini. I am still changing the code a lot, but when it stabilizes I'll do a VM plugin. I guess it would be about 100 times faster. The other option is to use Igor's NativeBoost. That could perhaps be 10 times faster than the plugin, at the cost of portability and hand written asm (I'd done lots of asm in a previous life).
Last year i built an SVG API bindings. And i were able to render the Tiger at screen refresh rate (65Hz). The rendering throughput is even higher than that, but it looks like SVG implementation limits the frame rate to screen refresh rate as maximum :)
Sure thing, the quality is not that high as yours, but still, it shows how much speed-up we could achieve, if we put all processing on GPU side.
It would be cool if we could cooperate and implement this stuff using OpenGL as backend
Indeed. Although I wonder if OpenGL is general enough to implement it... I mean, the only standard operation I do is to blend pixels... Everything else is done with new algorithms. Without being an OpenGL expert, I believe that CUDA / OpenCL would be better suited.
I don't know. But i don't think it is too different from many other techniques, which implemented using shaders. The rendering algorithms is highly parallelisable, that's why GPU is best place where they should run. And i guess, your algorithms is not an exception. I see there are two separate stages for rendering: 1. rasterize the path to mask (including pixel coverage) 2. fill the mask with paint Both can be implemented quite efficiently on GPU.
Cheers, Juan Vuletich
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.