Composite Set up - PreopenStack "everywhere"

Sannyasin Brahmanathaswami brahma at hindu.org
Fri Mar 10 00:06:41 EST 2017


We are using highly modular framework for our new app. 

Nothing like the IDE itself of course, but we are up to close to 50 *.livecodescript  text only scripts divided into behaviors, libraries, models  plus about 15 binarie.livecode stacks for modules and "views"…. and growing. 

I'm trying to optimize for small android devices and it seems the compositorType, tile size and cache limit are important. 

I have this in an init script that is a behavior on the main stack that opens when the app opens, card 1 has the init behavior that loads all the rest of the libraries and stack files

FYI the compositor was doing really, really strange things on my mac so I turned it off under development. Alsothe documentation and lesson on this is really lean, so if anyone has better, more detailed guidelines for best practices on this , please let us know:

I have this in the preopenstack handler

on preopenstack
   # some init routines, load and start using libraries
   # then this:

if the environment <> "development" then
     set the acceleratedRendering of this stack to "true"
     if the platform is "iphone" then
     set the compositorType of this stack to "opengl"
     else
     set the compositorType of this stack to "software"
     end if
     set the compositorTileSize of this stack to 32
     set the compositorCacheLimit of this stack to (16 * 1024 * 1024)
end if
     pass preopenstack
end preopenstack

Ok so this is working now and the rendering of the stack on my macbook pro doesn't go "kerpluey!" (strange rects, cropped group with black background other weird stuff, flickering graphic) and the app runs fine on the iphone and Android.

But apparently we need to have this set for every *[binary].livecode stack/view we launch, as the compositor setting is not persistent across a session. So the questions are two

1) The above is cut and paste from the online lesson on this subject. Please fire away with better tips on the best way to declare these settings. "software" obviously does not apply to all device besides iPhone, other wise it would not fail (intermittently) on my mac book pro.  The lesson says to multiply the rect of all your layers by 4… e.g. 10 layers: (10 x(400x400) x 4) what exactly does that mean.. ? what defines the rect of a given layer? the full geometric boundary around all the objects on that layer? or simply the rect of the card times the number of layers?

2) Given that this preopenstack handler is in a behavior on the card for the launching stack, it is not global. What is the best thing to do if we want the compositor to be set every time any other stack is opened? 

We have one lib_SivaSiva.livecodescript that we start using that serves as our app wide generic handlers "backscript". I have set preopenstack handles in backscripts before and sometimes it gets you into trouble if you start doing stuff that really should not be globally implemented.  But if I include this into that library

on preopenstack
     if the environment <> "development" then
     set the acceleratedRendering of this stack to "true"
     If the platform is "iphone" then
     set the compositorType of this stack to "opengl"
     else
     set the compositorType of this stack to "software"
     end if
     set the compositorTileSize of this stack to 32
     set the compositorCacheLimit of this stack to (16 * 1024 * 1024)
     end if
pass preopenstack
end preopenstack

Now it will fire every time any stack is opened. Is there some penalty for this method? My gut tells me that perhaps having these preopenstack handlers "lying around in the message path" is just not best practice. But maybe that just a "superstitious fear" 

Or maybe we should turn this into a discrete handler

command setUpCompositor
   # set the acceleratedRendering and compositor settings here

end setupCompositor

and then, call this discretely in a preopenstack handler in each separate stack. 
That somehow makes me feel better, not sure why.  Possibly because almost all the binary.lc stack in the framework *do* have preopenstack handlers already….

What do you recommend for 1) and 2)?

BR




More information about the use-livecode mailing list