<< Have not yet played with transitions to see if I can get tweened style strings out of them and convert but i cringe at the performance hit. >>
Just remembered attrTween and styleTween do allow that very easily and output the tweened style/attribute string, so that is possible too But in ay case what is really missing from the D3 [hacked together] reactive approach is a canvas differ so we don't have to trade necessary optimization for raw performance of canvas. On Sun, Jun 14, 2015 at 6:59 AM, Marc Fawzi <marc.fa...@gmail.com> wrote: > I totally trust your judgement. It could be flawed thinking on my part but > in D3 the generators for scale, svg line, stacked area, etc generate data > (configured by D3's related methods) which we can then translate to canvas > or webgl and before that we can put into the app state structure. So the D3 > approach while offering everything tightly integrated with the DOM is > hackable and can be adapted to state-driven/reactive views. In case of geo > projections of which D3 has so many the path function can output directly > to canvas. Have not yet played with transitions to see if I can get tweened > style strings out of them and convert but i cringe at the performance hit. > We just learned how to work with D3 in a half sane manner. I've even > introduced seamless immutability into JS specifically to deal with D3 apps' > prolific use of global mutable state and be able to minimize and isolate > shared mutable state into a single data structure (required only if > components you build require to share state which is the case in most > complex UI interactions) Your (or the Clojure) approach is much more > radically sane but i have not yet found the other pieces. For example, if > we're talking about reactive/immediate mode rendering then it would be nice > to have a virtual canvas that did the diffing so we could drive the whole > scene from app state and not have to repaint the whole canvas. > > Half baked thoughts... > > Sent from my iPhone > > > On Jun 14, 2015, at 4:49 AM, Karsten Schmidt <i...@toxi.co.uk> wrote: > > > > Hi Marc, > > > > thanks - but re: transitions - actually, not really. This module is > > intended to only do the actual mapping/visualization step in a longer > > pipeline. That is, you're responsible to provide a visualization spec > > with all elements & data pre-configured and this module will simply > > transform/visualize that current state. There might be some higher > > level transitions offered at some point, e.g. to tween between > > cartesian & polar coordinate mapping (example [1]), but this too could > > be achieved via a separate step injected before final serialization to > > SVG (or whatever). Unlike with d3 and other libs which are directly > > married to a DOM, here I try to approach this topic being completely > > format independent until the last moment, meaning all visualization > > methods will actually transform the viz spec into a scenegraph of pure > > data (types from the geom parent lib) and are only then translated > > into a concrete target format[2] (for SVG it actually transforms first > > into hiccup syntax). That pure data approach also means that any other > > type of transition can be easily achieved via other libs and I think > > any transition feature would be implemented outside the scope of this > > module. d3 tries to offer a one-stop solution addressing everything, > > but I think the Clojure way is to keep our options open. > > > > Having said this, I think transitions are very important and am v.keen > > to hear your feedback - I just don't want to go down a route which > > turns this into a monolithic can-do-everything and I think the > > approach taken allows for a number of higher level support modules, > > which you would simply plug into the transformation pipeline to > > compute intermediate, tweened visualization specs. For example, color > > transitions can be done via thi.ng/color, more general tweening via > > thi.ng/tweeny (and other libs)... > > > > Thanks, K. > > > > [1] http://haptic-data.com/toxiclibsjs/examples/polar-unravel > > [2] In this initial release that intermediate format is still > > outstanding and translation currently goes straight into hiccup > > format, but that's only temporary behavior... > > > >> On 14 June 2015 at 04:58, Marc Fawzi <marc.fa...@gmail.com> wrote: > >> Does the viz module aspire to catch up with d3 on the transitions > front? Awesome stuff and will definitely try out the API and make some > requests! > >> > >> Sent from my iPhone > >> > >>> On Jun 13, 2015, at 5:01 PM, Karsten Schmidt <i...@toxi.co.uk> wrote: > >>> > >>> Hi all, > >>> > >>> a new release of thi.ng/geom has just been pushed - now with the > >>> beginnings of a new clj & cljs data visualization module, currently > >>> supporting: > >>> > >>> - 7 layout/chart methods (bar, line, area, scatter, radar, contours, > >>> stacked intervals) > >>> - 3 axis types (linear, logarithmic, lens) > >>> - cartesian or polar mapping > >>> - flexible data input formats (via optional data item retrieval fns) > >>> - custom shape drawing fns > >>> - freedom to attach any other style/shape attributes (e.g. listeners) > >>> - extensive documentation > >>> > >>> Check it all out here (in glorious literate programming format!): > >>> > >>> https://github.com/thi-ng/geom/blob/master/geom-viz/src/index.org > >>> https://github.com/thi-ng/geom/blob/master/geom-viz/src/core.org > >>> > >>> The plan for this new viz module is to be output format agnostic, but > >>> it currently only supports SVG (which by all means will be the main > >>> use case anyhow) > >>> > >>> Other new things in this 0.0.856 version: > >>> > >>> - added voxel/isosurface examples > >>> - updated dependencies (clj-1.7,0-RC1, cljs-3308, thi.ng/ndarray > 0.2.0) > >>> > >>> Enjoy! K. > >>> > >>> -- > >>> Karsten Schmidt > >>> http://postspectacular.com | http://thi.ng | http://toxiclibs.org > >>> > >>> -- > >>> Note that posts from new members are moderated - please be patient > with your first post. > >>> --- > >>> You received this message because you are subscribed to the Google > Groups "ClojureScript" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an email to clojurescript+unsubscr...@googlegroups.com. > >>> To post to this group, send email to clojurescript@googlegroups.com. > >>> Visit this group at http://groups.google.com/group/clojurescript. > >> > >> -- > >> Note that posts from new members are moderated - please be patient with > your first post. > >> --- > >> You received this message because you are subscribed to the Google > Groups "ClojureScript" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to clojurescript+unsubscr...@googlegroups.com. > >> To post to this group, send email to clojurescript@googlegroups.com. > >> Visit this group at http://groups.google.com/group/clojurescript. > > > > > > > > -- > > Karsten Schmidt > > http://postspectacular.com | http://thi.ng | http://toxiclibs.org > > > > -- > > Note that posts from new members are moderated - please be patient with > your first post. > > --- > > You received this message because you are subscribed to the Google > Groups "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to clojurescript+unsubscr...@googlegroups.com. > > To post to this group, send email to clojurescript@googlegroups.com. > > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
