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).
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. McIntoshTwitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===
smime.p7s
Description: S/MIME cryptographic signature
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
