LiveCode Forums.

Hello Dear LiveCoders,

I need a -or more- runrev guru(s).
I'm fiddling around with the below properties for a while now:
compositorCacheLimit, compositorTileSize, compositorType.
But I couldn't see any performance benefits.

Here is a sample code:
A couple of questions:

* Does the order of these commands make a difference?
Setting the acceleratedRendering first or last;
or setting the compositorTileSize before the compositorCacheLimit, etc.

* What's the best way to determine the values of these properties?

* 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 ...


Any hints and info much appreciated.


Best,

~ Ender Nafi

Hi Ender,
The dictionary says:
"Use the acceleratedRendering property to put LiveCode into accelerated rendering mode and set the compositor properties to recommended defaults."
That means don't use both.

I'll let someone else answer your other questions, way over my head.

Simon

Thanks Simon,

I didn't think that way.
But it makes sense, now reading your reply.
One shouldn't use both.

Still wondering though, whether changing that settings makes any performance boost.

I'll post the question in the mail list, too.
There are plenty of gurus there
and I think many of 'em can't find much time to read the forum posts.

Thanks again Simon...

Best,

~ Ender Nafi

Ok,
It was a good decision of me to post this question to the mail-list.
The roundup of Jacque's detailed answer:
*
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 one should use it only when one need it.
*

And here is Thomas McGrath's clarification from another post:
*
1. on preopenCard - set the acceleratedRendering of this stack to true (only on cards that have scrolling or dynamic groups/objects
2. Immediately before moving an object turn on dynamic or when scrolling a group turn on scrolling
once moving the scroll or object has already been cached and drawn so these are no longer necessary.
No need to turn these things on and leave them on because they are not needed and the result is that things will actually slow down.
3. Immediately after moving or scrolling an object turn off the scrolling or dynamic settings
4. on closeCard - set the acceleratedRendering of this stack to false (turn it off since it is not needed)
*


So, here is the recipe:

If you don't have any scrolling groups or moving objects
-> don't turn on acceleratedRendering
and keep the layerMode of controls of the card as static.

If you have a scrolling group
-> turn on acceleratedRendering
and set the layerMode of group {only the topmost group, not the objects of group} to scrolling
immediately before scrolling;
then turn off acceleratedRendering
and set the layerMode of group to static after scrolling.

If you have a couple of moving objects and they move on occasion {i.e. following a click / touch}
-> turn on acceleratedRendering
and set the layerMode of the object(s) to dynamic immediately before the move;
then turn off acceleratedRendering
and set the layerMode of the object(s) to static once the move is done.

If you have multiple moving objects and / or they move constantly
{falling snow particles or rain drops, zooming stars like the Windows' simple screensaver, etc.}
-> turn on acceleratedRendering in the preOpenCard handler
and set the layerMode of the respective object(s) or group(s) to dynamic;
then turn off acceleratedRendering
and set the layerMode of those object(s) and / or group(s) to static
in the closeCard handler.


If I did any mistake or misunderstood the concept, please correct me.


Best,

~ Ender Nafi

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:
Thanks everyone, especially Jacque...


Regards,

~ Ender Nafi

Ender, that certainly helps with the actual scrolling of my data grids, but there is a slight delay each time the scrolling starts (I have to check for which one of three data grids are being scrolled).

So close

Gerry

So close

So close, indeed

Once I find a solution for that delay, I'll post it here.


Cheers,

~ Ender Nafi

how can objects move constantly, and then how can i stop them?