On Mon, Sep 13, 2010 at 12:49 AM, John M McIntosh
<johnmci at smalltalkconsulting.com> wrote:
> Spent a few more hours today reading and  then decided the test case I had from Bert spent 90% of it's time in the interpreter's
> copyLoop logic.  Toss that for the fall back of using bouncing atoms so I could get a better feel of the performance differences.
>
> So after some optimization, on the iPad, the CALayer pushes about 38 fps,  the OpenGL code pushes 49 fps (which is limited by Morphic loop).
----------------------------------------------------------------------------------
Would it be possible to remove the Morphic loop by compiling it away?
I have seen an assembler for Squeak called E...something and I have
the start of one in Dolphin in picoLARC which does all the addressing
modes but only has one instruction the ADD but adding more
instructions should be easy but I don't know about those extra bits
that come up here and there.  I hoped to make a lisp dialect
equivalent to C and then compile that into the assembler which is also
a lisp dialect.  Everything in picoLARC is in Smalltalk or a lisp
dialect which is equivalent to some other language with an OOP macro
system across all the dialects.  So each lisp dialect would get
compiled in stages into the CLisp dialect and then into assemblerLisp
and then into the machine.  My brain got fried one day and I quit
working on it.  I think I need a GUI representation of the lisp stack
to keep that from happening again.
----------------------------------------------------------------------------------
>
> In checking Instruments the 10% of the time taken in CALayer for memcpy of data out of the UIImages is gone when I do open/GL
> However if the drawing area becomes too big then the Open/GL drawing is slower, trade offs, trade offs.
>
> Also the byte alignment plays a part, that I have to explore more.  Still this is significant progress and we'll see what happens this week.
>
> A quick check on an iPhone 3GS shows CALayer pushes about 27fps, OpenGL does 43 fps. So much bigger win, I think we'll keep it.
>
> Sadly it doesn't fly on an iPod Gen 1 device (3.1.3) Zero clues.. It's possible of course there isn't isn't enough memory to go around, but
> given I've two different implementation classes I can choose the viable one at run time...
>
>
> On 2010-09-11, at 3:37 PM, John M McIntosh wrote:
>
>> On friday night I created an open/GL renderer to work with Squeak screen updates on the iPhone/iPad.
>>
>> Unfortunately it runs slows than the tiled Core Animation render that I had work out earlier in the year
>> with help from the Apple graphics engineers.
>>
>> So if anyone has a fair amount of knowledge about Open/GL ES maybe they could contact me and
>> we'll see if we can improve things?
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
>
>
>