First real world implementation... The results are spectacular A 16.000 px high group of news does scroll flawlessly in my low-end test device iPod Touch. Before this retouch, it was scrolling bumpy. Btw, each news group contains a 128*128 px picture, two text fields and a button.
Here is a snippet of my code: *** on scrollerBeginDrag __set the layerMode of group "theNews" to "scrolling" __set the acceleratedRendering of this stack to true end scrollerBeginDrag on scrollerDidScroll pX, pY __switch mobileControlTarget() ____case "theNewsScroller" ______set the vScroll of group "theNews" to pY ______break __end switch end scrollerDidScroll on scrollerEndDecelerate __set the layerMode of group "theNews" to "static" __set the acceleratedRendering of this stack to false end scrollerEndDecelerate *** Thanks everyone, especially Jacque & Thomas McGrath... Regards, ~ Ender Nafi ~ · Keehuna Studio ~ · Sorcerers of Design On Tuesday, February 19, 2013 at 11:53 PM, Ender Nafi Elekçioğlu wrote: > Thank you Jacque, > You've been helpful, as always. > > I understand that there's no need to mess around with the compositor > properties. > Leaving the defaults as is and using the acceleratedRendering is enough. > But the tricky part is I should use it only when I need it. > Well, that's a good advice. > > I'll read the old posts about the acceleratedRendering further. > > > Thank you very much. > > Regards, > > > ~ Ender Nafi > > ~ · Keehuna Studio > ~ · Sorcerers of Design > > > On Tuesday, February 19, 2013 at 11:37 PM, J. Landman Gay wrote: > > > On 2/19/13 2:36 PM, Ender Nafi Elekçioğlu wrote: > > > > > Asking in the forums is easy, > > > however asking a question in the mail-list is a bit intimidating, I must > > > confess. > > > > > > > > > We're mostly the same people, only there are a few more on this list. > > Don't worry, we're mostly friendly. Ask us anything. That's what we're > > here for. > > > > > -> Does the order of these commands make a difference? > > > Setting the acceleratedRendering first or last; > > > or setting the compositorTileSize before the compositorCacheLimit, etc. > > > > > > > > > The usual place to do the settings is on preOpenCard, so I don't think > > the order matters. Nothing happens until an object moves, and they won't > > move before the card is drawn. The only exception is the > > acceleratedRendering property itself. Turn it on before things are about > > to move, and turn it off when the move is finished. Leaving it on when > > no objects are moving can slow performance. > > > > > > > > -> What's the best way to determine the values of these properties? > > > > Good question, and I used to have a message from RR about that but I > > can't find it now. There was a sort of formula, but it was generic and > > not always reliable because devices vary so much. Eventually RR just > > provided defaults and I always use those, because calculating an exact > > setting isn't reliable anyway. I've found the defaults work pretty well. > > > > > > > > -> In which scenarios do these commands create a performance boost? > > > For example, in a game which consists hundreds of buttons and > > > thousands of sprite png's or ? > > > > > > > > > You need acceleratedRendering when objects move quickly and often. The > > game example is a good case for it. You'll have to use some judgement. > > If things on a card are constantly moving then turning it on on > > preOpenCard and turning it off on closeCard is fine. If the only thing > > that moves is a scrolling group or field, then turn it on when the user > > starts to scroll and turn it off when they're done. > > > > There is a lot of info in the list archives, which you can see on either > > Nabble or Gmane. This link is a start: > > <http://runtime-revolution.278305.n4.nabble.com/acceleratedRendering-is-my-friend-td4651360.html> > > > > Also, if you search Nabble for "acceleratedRendering" you'll get more hits. > > > > -- > > Jacqueline Landman Gay | [email protected] > > (mailto:[email protected]) > > HyperActive Software | http://www.hyperactivesw.com > > > > > > _______________________________________________ > > use-livecode mailing list > > [email protected] (mailto:[email protected]) > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > > > > > > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
