> > You could send strings for function blocks that can later be eval-ed. > But the eval itself might slow things down a lot. > yep, also it's not recommended ( http://javascript.crockford.com/code.html, look for "eval is evil")
Some browsers serialise the JSON to > string and then re-eval it, others send the actual object. > afaik, ff takes the message and then converts it to JSON.. 2009/8/26 Lucian Branescu <lucian.brane...@gmail.com> > You could send strings for function blocks that can later be eval-ed. > But the eval itself might slow things down a lot. You can also send > JSON objects between workers. Some browsers serialise the JSON to > string and then re-eval it, others send the actual object. > > About shared data, try to stay away from it anyway. Message passing is > desirable most of the time. > > 2009/8/25 Felipe López Toledo <zer.subz...@gmail.com>: > > Hi > > in my early post I talked about > > canvas vs SVG (slide #28) > > why not processingJS? (slide #28) > > here some technical stuff: > > --- > > Browser Optimization (slide #29) > > Karma lessons must run under the XO-1. > > Default browser: Browse ( based on Gecko ) > > Experimental: Surf ( based on webkit ) > > No problem with html elements (div, img, ...) > > What about canvas content? > > Under a normal browser clearing and redrawing the canvas objects may not > be > > a problem, but remember that the XO has not that kind of normal > resources. > > We must use them efficiently. > > If we have no option, it's preferable to spend cpu than spend memory. > > We emphasize rendering speed over quality > > image-rendering / firefox 3.6 alpha > > webkit has nothing > > Quadrilaterals (http://karma.sugarlabs.org/quadrilaterals/) > > how does it work? > > 2 canvases > > the first for temporal drawing of the current line > > cleared and re drawn when "mousemove" > > the second has the drawn polygon, background, etc.. > > Quadrilaterals under Browse has a severe lag problem (unusable) > > Quadrilaterals under Surf works nice > > Surf-106 is faster than Browse-102, should we use Webkit or Gecko? > > -- > > Web Workers (slide #30) > > We tried to use web workers to handle animations: an animation core. > > The animation core would be running as a worker thread: doing the > neccesary > > calculations for the animated objects and sending messages to the root > > document to manipulate (update) the neccesary html elements (canvas...) > > We try to combine actions with predictable behaviour. > > Problems: > > it's not possible to send functions as worker messages, so, it's hard to > use > > callbacks. > > how to share memory (variables) between the root document and the worker > > thread without copying that data? > > -- > > 2009/8/21 Christoph Derndorfer <christoph.derndor...@gmail.com> > >> > >> Hey guys, > >> I basically agree with the points raised here so far and have a couple > to > >> add myself: > >> slide #11: I would also mentioned that you had tried eToys/Squeak > >> slide #24: I'm not sure we agreed on each lesson having to include a > >> tutorial and an exercise. Of course this is a good goal but the question > is > >> whether we should really make that a requirement? > >> slide #32: "i81n";-) > >> slide #43: add link to Karma blog at http://karmaproject.wordpress.com/ > , > >> add at least one e-mail address for direct contact, add link to Sugar > >> mailing-list (http://lists.sugarlabs.org/listinfo/sugar-devel) > >> That's all I can think of for now... > >> Christoph > >> 2009/8/21 Felipe López Toledo <zer.subz...@gmail.com> > >>> > >>> Hi guys > >>> > >>> Joshua, Bryan has talked Christoph and me about you, thanks for writing > >>> :) > >>> > >>>> * I would update the slide "Nobody Wants to Help", to something like, > >>>> "Flash is a poor longterm solution." I would drop the claim "Flash > Devs > >>>> don't like to share." I would > >>>> - Despite the great work of the free software community on projects > >>>> like Gnash and the GameSWF library, there is very little in terms of > sharing > >>>> and collaboration of free software Flash projects. > >>> > >>> +1 > >>>> > >>>> - There is no free software Flash development tool, > >>> > >>> mmm, I remember MTASC http://www.mtasc.org/ > >>>> > >>>> instead almost all Flash development is done through the proprietary > >>>> software created by Macromedia. > >>> > >>> +1 > >>> > >>> Bryan, really good draft, here some initial feedback: > >>> > >>> 1. SVG vs canvas > >>> I used RaphalJS (http://raphaeljs.com/) demos to test SVG animatios > using > >>> Browse and Surf, > >>> results: > >>> under surf: the XO crashed several times :( > >>> under Browse: the animations look really good, but the performance is > >>> really bad (you will get a several lag when clicking something, etc...) > >>> > >>> canvas is low level so, canvas drawing is faster than SVG drawing. > >>> about manipulation, well, It's really easy to manipulate SVG Objects > >>> (everything you draw is an object) but canvas is just a box where you > can > >>> draw, Karma provides (some of) that objects. > >>> > >>> 2. why not processingjs? > >>> processingjs by default uses processing language, then if you want to > use > >>> it you'll need to learn processing syntax... to support that syntax, > >>> processingjs uses a parser, so, it's slower than simple JS. > >>> in fact, you can use javascript to access processingjs objects, but.. > the > >>> actual processingjs library is not designed to work under the XO, > neither to > >>> work as a jQuery plugin. > >>> I think jresig doesn't encourage to use processing (syntax), he just > take > >>> processing because processing was there (looking for the reference) > >>> > >>> I will add more info on the technical stuff. > >>> > >>> regards > >>> > >>> On Thu, Aug 20, 2009 at 7:57 PM, Joshua Gay <j...@ck12.org> wrote: > >>>> > >>>> Bryan, > >>>> > >>>> This is looking good so far. Here are some initial thoughts, > >>>> > >>>> * It would be good to have a handout that puts all this info on a > single > >>>> double side sheet of paper (a suggestion taken from Edward Tufte's > essay > >>>> "The Cognitive Style of Powerpoint) for people to read along with and > to > >>>> look at afterward. > >>>> * I think overall it can be trimmed down abit when it is being pitched > >>>> to specific groups (e.g., JS crowd). > >>>> * I would update the slide "Nobody Wants to Help", to something like, > >>>> "Flash is a poor longterm solution." I would drop the claim "Flash > Devs > >>>> don't like to share." I would > >>>> - Despite the great work of the free software community on projects > >>>> like Gnash and the GameSWF library, there is very little in terms of > sharing > >>>> and collaboration of free software Flash projects. > >>>> - There is no free software Flash development tool, instead almost > all > >>>> Flash development is done through the proprietary software created by > >>>> Macromedia. > >>>> * I would introduce some more lucid examples of the kinds of things > you > >>>> would like to use this library to create. > >>>> > >>>> > >>>> I had some other thoughts on the internationalization parts, too. I > will > >>>> try to respond later with them. The short of it is that I think the > examples > >>>> you gave me (in our phone call) about gettext being an > overly-burdonsome > >>>> approach for JS made a lot of sense and I think it would also help to > >>>> explain that you are looking for the JS equivalent of gettext; kind of > >>>> abstract this part away from your specific needs as an organization, > and > >>>> talk about how this could benefit projects in general. > >>>> > >>>> -Josh > >>>> > >>>> On Thu, Aug 20, 2009 at 12:51 PM, Bryan Berry <br...@olenepal.org> > >>>> wrote: > >>>>> > >>>>> josh, kcd, subzero > >>>>> > >>>>> 1st off, let me introduce Josh Gay, a js dev and free textbook guru. > He > >>>>> is interested to make a presentation about karma to the JS devs group > >>>>> in > >>>>> Boston on Aug 27th. > >>>>> > >>>>> here is a more technically-oriented presentation for karma > >>>>> > >>>>> It is long on introduction and short on technical details. Much of > the > >>>>> first part could be cut out depending on the target audience. I made > it > >>>>> longer and more general for my first draft. > >>>>> > >>>>> It lacks a lot of technical detail on what we need help w/ for > >>>>> animation, i18n, web workers, localstorage > >>>>> > >>>>> -- > >>>>> Bryan W. Berry > >>>>> Technology Director > >>>>> OLE Nepal, http://www.olenepal.org > >>>> > >>> > >>> > >>> > >>> -- > >>> Felipe López Toledo > >>> > >>> _______________________________________________ > >>> Sugar-devel mailing list > >>> Sugar-devel@lists.sugarlabs.org > >>> http://lists.sugarlabs.org/listinfo/sugar-devel > >>> > >> > >> > >> > >> -- > >> Christoph Derndorfer > >> co-editor, olpcnews > >> url: www.olpcnews.com > >> e-mail: christ...@olpcnews.com > > > > > > > > -- > > Felipe López Toledo > > > > _______________________________________________ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > -- Felipe López Toledo
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel