[Sugar-devel] [karma] early draft of karma presentation

[Felipe López Toledo]

>
> 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.branescu at 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.subzero at 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.derndorfer at 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.subzero at 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 <jgay at 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 <bryan at 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 at lists.sugarlabs.org
> >>> http://lists.sugarlabs.org/listinfo/sugar-devel
> >>>
> >>
> >>
> >>
> >> --
> >> Christoph Derndorfer
> >> co-editor, olpcnews
> >> url: www.olpcnews.com
> >> e-mail: christoph at olpcnews.com
> >
> >
> >
> > --
> > Felipe López Toledo
> >
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>



-- 
Felipe López Toledo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090827/39fc8159/attachment.htm