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 > > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel