Juan Vuletich wrote:
> Hi Joshua,
>
> Joshua Gargus wrote:
>> ...
>>> May be you're right, but as I'm only rendering 2d objects, the
>>> computational cost should be much lower than for ray tracing.     
>>
>> It depends on what kind of non-affine transforms you want to render
>> with, since this will determine the cost of each intersection-test.  For
>> arbitrary transforms, these interesection-tests can become arbitrarily
>> expensive.
>>
>>   
> Not sure what you mean. In my implementation there are no intersection
> tests. At each pixel, every morph is asked for its value there
> (actually, the coordinates are transformed to the morph's space before
> asking). The morph might answer transparent, if the point falls
> outside it. The transformation of coordinates is done before asking
> the morph, so the only code that can get more expensive is the
> transformation itself. The code for the morph, something like
> #colorAt: is the same regardless of the transformations involved.
>
> If this doesn't make sense to you, please elaborate, so I can follow
> you better.
That's fine, it makes sense.  I was thinking that you might be doing
something more complicated than you are (which would be fun to go into
over a beer, but I'm sure that I would fail to get it across via email).

>>> Besides, if Morphic 3 turns to be usable only with help from OpenCL or
>>> CUDA or some other special hardware, it is not too bad.
>>>     
>>
>> My first thought when I read your original post was "how is he planning
>> to take advantage of graphics hardware?".  In order to use OpenCL or
>> CUDA effectively, you need to set up a parallelized workload for the GPU
>> to munch through.  The implementation you describe ("for each pixel,
>> iterate over the morphs, starting at the one at the top, and going
>> through morphs behind it, etc...") requires a traversal of the Morphic
>> scene-graph for each pixel.  A CUDA program running on the GPU can't ask
>> Squeak for information about which morph is where... all of the GPU
>> processors will pile up behind this sequential bottleneck.  Do you have
>> some idea of how you would approach this?  It seems like you'd need to
>> generate (and perhaps cache) a CUDA-friendly data structure.
>>   
>
> Hehehe. You're right! Today I'm experimenting with an idea. I'd like
> to traverse the morphs graph (actually a tree) and for each morph
> iterate over the pixels. This would require an enormous amount of
> memory, to compute all pixels in parallel. What I'm trying to do, is
> to iterate blocks of, let's say, 32x32 pixels. For each block,
> traverse the morph graph. At each morph (actually at each "shape"),
> compute the effect of it over each pixel in the 32x32 block. To do
> this, instead of building just one "color stack" I need to build 1024
> of them (32x32). This is a reasonable amount of memory. The work
> inside each shape, with 1024 pixels can be parallelized and be made
> CUDA friendly. The data structures involved at this step are some
> float arrays and float stacks.
>
> Besides making it CUDA friendly, it will divide the cost of fetching
> the Smalltalk objects and traversing the tree by a factor of 1024.
> This should have a big effect on performance!

Neat idea!  The Larrabee paper at SIGGRAPH (which I seem to constantly
be recommending to people) describes a tile-based rendering pipeline
that is similar to this.

http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

>> Stepping back, one of the main difficulties I have when thinking about
>> how rendering should work in Morphic 3 is that I don't really understand
>> what the end-user APIs will look like.  For example, suppose that I
>> program a graph that plots data against linear axes (each data point is
>> rendered as a circle).  If I want to instead plot data against
>> logarithmic axes, I can't simply render the whole graph with a different
>> transform, because the circles will no longer look like circles.  How
>> could this be avoided?  I can't see how.
>>   
>
> You're right again. This is one of the problems I had open without
> finding a solution for several years now. So far, circles won't look
> like circles anymore. I believe that should be the default behavior.
> If the graph is logarithmic, everything gets logarithmic!
>
> However I understand that an application might want those circles to
> look like circles, or to add text labels that look like regular text,
> etc. I still haven't worked it out completely. But I envision some
> morphs (the circles and the labels), that live inside an owner with
> logarithmic coordinates, and they can say something like "instead of
> transforming pixel coordinates all the way down to my parent for me to
> render, stop at my grandparent, and translate my parameters (circle
> center and radius, etc) to its space, and render there". It can be
> done. I'm still not sure on how the programmer should specify this. I
> don't want to drive programmers crazy!

Are you planning to use the same transform on the whole screen, or do
you have ideas about how to use different transforms in different parts
of the screen (or different sub-trees of the morph hierarchy)?  If the
latter, I can imagine explicitly referring to outer transforms to
transform some properties (eg: circle radius) while letting others use
the default transform for that context (eg: the circle's center would
use the logarithmic transform).  If there were reified slots, like in
Tweak, then the transform to use could be attached to the slot (with nil
meaning the default transform w/in that context).

Half-baked, I know :-)

Cheers,
Josh

>> I think that the idea of rendering entire scenes with arbitrary,
>> non-linear transforms is very cool.  However, I don't see how it would
>> be very useful in practice (for reasons like the example above).
>> Hopefully, I'm just missing something, and you'll be able to explain it
>> to me.
>>
>> Cheers,
>> Josh
>>   
>
> I hope what I said above makes sense to you. However, this is
> experimental stuff. I hope it will turn out to be very useful. Only
> time will tell.
> Thanks for your interest!
>
> Cheers,
> Juan Vuletich
>