+1 on moving away from the imperative/java in clojure approach.
May be interesting to look at penumbra<https://github.com/ztellman/penumbra>
and
elm <http://elm-lang.org/> for inspiration? I'm sure Zach Tellman has/had
some thoughts on the subject.
Just my 2 cents.
On Friday, March 14, 2014 5:18:26 PM UTC-4, Omer Shapira wrote:
>
> Very true, but for more than just the occasional doodle, this idea needs
> to be complete, because pipelines like OpenGL/WebGL use imperative calls.
>
> One way of doing it would be keeping the entire state of the OpenGL
> context (not including data) cached as an object and just interact with it,
> so a lot of imperative code (pushmatrix/popmatrix, for example) could be
> automatically resolved, and just treat the output as a transient would be
> treated, since there's no other way to send data to it.
>
> Three.js does a nice job of encouraging that sort of dataflow, but I feel
> it could definitely be shorter if it was written in a way that resembles
> C++ less. If anyone has a background in this, I would love to discuss this
> in more detail.
>
>
> On Friday, 14 March 2014 11:15:32 UTC-4, Adam Clements wrote:
>>
>> I'm keen to see graphics frameworks on clojure move away from imperative
>> api call wrappers and towards a more declarative approach, where you define
>> as data what you want to draw. I have done this for a number of personal
>> projects, using a hiccup like syntax to define my drawing operations, and
>> then have a thin rendering layer which takes the generated data and draws
>> it each frame/refresh etc. Longer term you could do far more clever things
>> with this approach like only redrawing what you need to, rendering sub
>> elements together and then compositing the final image etc. plus it would
>> be easy to implement this cross platform - it's just data.
>>
>> For example:
>> [[:line {:colour :black :thickness 5} 0 0 20 20]
>> [:circle {:colour :red :fill true} 200 200 20]
>> [:text ....]]
>>
>> and so on. Defining basic drawing operations like this would be easily
>> extensible, attributes could be added, and rendering engines which don't
>> support all the features (say if you added a drop shadow attribute) could
>> degrade fairly gracefully. You can also save this nicely. Think of it like
>> a lispy SVG format, where you can manipulate graphics using higher order
>> functions.
>>
>> You could also apply transforms using nesting and define things like
>> (defn box [attrs x1 y1 x2 y2] [[:line attrs x1 y1 x2 y1] [:line attrs x2 y1
>> x2 y2] ...]) which could be quite nice, giving you something like:
>>
>> [:transform {:rotation 30} (box {:line-thickness 5} 0 0 50 30)]
>>
>> Obviously all of this would need to be ironed out and the exact semantics
>> smoothed over, but what do people think in principle to a more declarative
>> graphics library which could then be optimised far more than manual api
>> calls ever could while encouraging a clean functional, testable approach.
>>
>> Adam
>>
>>
>> Adam
>>
>>
>> On Thu, Mar 13, 2014 at 10:37 PM, Omer Shapira <[email protected]> wrote:
>>
>>> Hey,
>>>
>>> I'm applying to GSoC this year, and I'm looking for mentors.
>>>
>>> I want to create a cljs-idiomatic web graphics package. I have graphics
>>> programming experience, being a member of the Processing and openFrameworks
>>> communities, and a researcher at Ken Perlin's lab at NYU.
>>>
>>> While I'm still learning Clojure's abstractions, I have been programming
>>> in Scheme for a long time.
>>>
>>> Anyone who wants to mentor me / chat about some ideas can reply here or
>>> find me at http://omershapira.com
>>>
>>> Thanks!
>>> Omer
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to [email protected]
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
