Hi David, On Tue, Nov 8, 2011 at 6:23 PM, David Barbour <dmbarb...@gmail.com> wrote: > >> The high-level model of computation is a variation of Kahn process >> networks. The low-level part is a single-assignment, >> mathematics-oriented language for specifying the internal behavior of >> a process. > > I've been reading through Nile and Gezira code and understand the model > better at this point. It's basically pure functional stream processing, > consuming and generating streams. I understand that `>>` generates one > output, and `<<` seems to push something back onto the input stream for > re-processing.
Yes, you are correct. The spacial metaphor here is that streams flow from left to right, so ">> x" pushes x to the right, onto the tail of the output stream. "<< x" pushes (pulls? :) x to the left, onto the head of the input stream. Pipeline construction works this way too, e.g., ClipBeziers → Rasterize → ApplyTexture → WriteToImage . A bit silly, perhaps, but it works. "Input prefixing" is what I call this pushing of data onto the input stream, though I'm not set on that term. You used the term "pushback", which I like, but the problem is that we're pushing onto the _front_ of the input stream, and "pushfront" just doesn't have the same ring :) Whatever the name, this feature is vital to writing expressive programs in Nile. It provides a recursion-like capability. For example, the DecomposeBeziers process successively decomposes Beziers until they are small enough to process. This is done by splitting the Bezier into two parts (à la De Casteljau), and pushing each sub-Bezier onto the input stream. I have never seen input prefixing in a stream-processing/dataflow language before. I could only find one passing reference in the literature, so unless someone points me to previous art, I'll be playing this up as an original contribution in my dissertation :) > Which Nile operators do you anticipate would translate poorly to shaders? I > guess `zip` might be a problem. SortBy and pushback operators - at least if > finite - could be modeled using shader global state, but that would be a bit > of a hack (e.g. receive some sort of EOF indicator to emit final elements). > Hmmm.... Yes, this is the beginning of the difficulties. Just taking the input prefixing issue, it's problematic to model the unbounded input stream as global state. You have issues because of the finiteness of the global state, and because of the inefficiency of global write/read access in the shader (see GPU docs). And as I brought up before, even if one can get something to run on the GPU, that's very different from getting something to run much faster than on the CPU. Regarding your question about which processes would map poorly: the built-in Nile processes DupZip, SortBy, and Reverse (maybe DupCat, too). Many Gezira processes are a problem, such as ExpandSpans, CombineEdgeSamples, ClipBeziers, DecomposeBeziers, pretty much all of the processes in the file stroke.nl (pen stroking). There's probably more, these are off the top of my head. > I think I'd be in trouble actually writing Nile code... I don't have a text > editor with easy Unicode macros. Which do you use? I use vim. So I hit "ctrl-v u2200" for ∀. Ideally, we'd have a Nile IDE with keyboard macros in addition to a little char map to click on (Bert built one for Frank). The theory behind using Unicode in Nile is that source code is read a lot more than it is written. So I'm willing to make code a bit harder to write for a payoff in readability. And if Nile becomes what it should be, one shouldn't have to write much code anyway. > I agree that Conal Elliott's focus has certainly been on composable, > morphable, zoomable graphics models I'm glad we agree...wait a second...when did I say the above? > - primarily, everything that happens > before rasterization. Ah, well, now I don't agree that his focus has been on "everything that happens before rasterization." He's left out a lot. He's never taken on pen stroke approximation (which is vital for 2D vector graphics). I had to struggle a bit to come up with my functional approach to pen stroking (if I missed prior art, let me know!). He's never taken on, say, analytical geometry clipping. On top of that, there's a lot _after_ rasterization, and he doesn't addresses that territory much either. I like Conal's work, really. I read all his papers on functional graphics several years ago, and it probably subconsciously influenced my research. I'm just objecting to the idea that he covered very much functionality in the computer graphics space. I think he took on the easiest niche to model in a purely functional language. > Anti-aliased rasterization can certainly be modeled in > a purely functional system, Easier said than done, I think. Again, I struggled quite a bit to come up with the Gezira rasterizer (which is basically purely functional). I don't know of any previous anti-aliased rasterizer done in a purely functional style, do you? Pointers appreciated. You could just reproduce Foley et. al, but that's such an imperative algorithm, I would think you'd end up with C-in-Haskell looking code. If so, I wouldn't count that. > Are you trying anything like sub-pixel AA? (seems a bit too system dependent > for me, but it's an interesting subject.) I also find it interesting, but I haven't tried it, yet. Just thought through what the pipeline would look like and how to do the fitering. Definitely worth doing at some point. > My own interest in this: I've been seeking a good graphics model for > reactive systems, i.e. rendering not just one frame, but managing > incremental computations and state or resource maintenance for future > frames. I don't think Gezira is the right answer for my goals, I think you're probably right. Gezira is fundamentally about the ephemeral process of rendering. Managing state and resources is a whole other ball game. At Viewpoints, I think the Lesserphic project is closer to what you're looking for. Thanks for the engaging questions, Dan _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
