Re: Optimizing for small Android devices

[Bob Sneidar via use-livecode]

So did Russia BTW. But Germany's problems were not simply that the tanks were 
more complex and expensive to manufacture. They were suffering from a severe 
shortage of materials, and also some design problems. The Tiger as I recall had 
a turret that had to be hand cranked. They were also so heavy and guzzled so 
much fuel that large supply lines were necessary, and any terrain that was 
muddy tended to strand them. The battle of the Bulge basically ended when the 
Germans ran out of fuel. 

Sorry for the OT comment. 

Bob S


> On Dec 29, 2017, at 18:59 , Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> I certainly did not mean to imply by "only" that pointed to the market share 
> of phones with 1 GB ram.
> 
> OT: I was just reading Quora about how US overwhelming Germany with sheer 
> numbers of tanks and jets that had much lower specs than German made 
> tanks/planes. But we won on our sheer industrial power to produce numbers.  


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

Mark: Wow, yes, it does help! I hope you had a great Christimas and are 
refreshed ready to face all of us again (smile)

Your entire email should be posted to some knowledge base somewhere!

As for speed optimization:

-
Alternate images

I will make 1 X images right away for my home "portal" screens heros which are 
now 2 X and rename the current ones to 

Looks like that should be
h...@medium.jpg  # exact size of the image object as defined in points/pixel in 
LC.
hero@extra-high # for the 2X version

Prepare (command):  yes this could help in a number of instances, I will try 
it. 

--

Further questions

… you are right, we are not doing a lot of intensive data processing. My quick 
run with script profiler showed that some operations I thought we hurting the 
app were in fact taking a trivial amount of time. which means we can focus on 
the graphics, clearly the "problem." . I scoured the dictionary, but could not 
find any method determine amt device RAM, which I suppose is mute since the 
user could open as many apps as he likes and push the device to the wall, 
leaving little for LC… and there is nothing we can do about that.   

RE: image cache?  This is new info to me… Very unlikely we would exceed the 
default 64 MG for mobile. But that default makes one wonder. Because we are 
told that the max RAM allotted to an app on Android is 57MB…so if the total MB 
of images used on a card < 64… and we navigate to another stack or card in the 
same stack… does the cache retain images from the previous card, stack? If so 
then eventually the cached images will overtake the available RAM on the device 
if we leave it at the default.  is that correct?  If so,  then it means we 
*should* be doing some calculations and lowering the cache limit for Android. 
which again is "new info…."  

Also what if you are heading into a module/stack which is graphic intensive ?  
Like our word puzzle in the app and other possible "mini games in a stack" …  
if all previous images are cached, would it make sense to deliberately flush 
the cache before we start creating our puzzle (takes snap shots of fields, 
saves these as images and then distributes them as "tiles" across the card… )  
if so, how does one do that? I don't see a flush cache command…

RE: Multiple Instances of same graphic/image on Card?  OK we are generating 
"lists" using a Parent Group with subgroups as "rows" (like DataGrid) where 
these Rows" contain image… in some case we are using a SVG Widget to show a few 
icons in the row.. these are attached to a template group on card 2… replicated 
over and over again down the screen dynamically on cd 1… There may be contexts 
where the repeated grc is  
a) a button with file on disk assigned as icon 
b) or just an image referenced by the template group that is on disk.

OK so now the card has 100 rows… with multiple instances of the exact same: SVG 
icon (as widget the same one icon) OR multiple button(s) with the same img file 
as icon OR a small image which has multiple instances on the card but each 
references the same, one only file on disk.  I presume this question applies to 
the DataGrid as well. (which I have yet to use…) 

I think the question is obvious: are all these little visual reps of a single 
graphic a) occupying only the value of (1 X (their un compressed size) in RAM  
or does the RAM now hold ( N (number of appearances on the card) X (their 
uncompressed size) as a cumulative total in RAM?

RE: images streamed to the app from a server in advance with "Load" ? ….  are 
these cached automatically or should we load and prepare each one after it 
arrives?

RE:  acceleratedRendering, Navigation across stacks and Redraw issues?

please see  

http://quality.livecode.com/show_bug.cgi?id=20810

which is rather urgent as we went live on Google Play and I need an update that 
fixes this asap.

FWIW here is the entire handler that does almost all the work of navigation 
across many modules(stacks) (and many more to come)  could you re-write this 
for us to what you would consider the optimal SOP/ best practice, using Go in 
window… where 

AcceleratedRending is 
a) one in the stack we are closing
 b) needs to be turned on in the stack we are opening…

I could try myself, but frankly, I would rather you give us the "bottom line" 
method here if you would not mind as I'm getting a bit tired of wrestling with 
this on Android (over a year now!) impossible to debug when script run fine an 
d is works on iOS and desktop…

command portal_GoStack cardOrStackObject  

   put the short name of this stack into oStackName

   put "Siva-Siva-App,Journal,view_SivaSivaBrowser"  into tNoGoBackStacks

   if (sLastStack="Journal") AND (cardOrStackObject <> "Journal") then 
  # it means we are launching activity and we are not actually going
  # to the view the journal, in which case we have to be sure it closes
  put "Journal" into oStackName
   end if
   if (not  (oStackName is among the 

Re: Optimizing for small Android devices

[Mark Waddingham via use-livecode]

On 2017-12-27 06:04, Sannyasin Brahmanathaswami via use-livecode wrote:

Any thoughts in this area?


In terms of images / screen resolution etc...

The first thing to ensure is that *all* your images objects use the 
filename property rather than embedding the image data in the stackfile 
via the 'text' property.


One exception: if you are constructing images on the fly temporarily 
(i.e. for a single card) then the 'text' property is still the best 
choice.


The size of the image files on disk is not really relevant - what 
matters is the amount of memory they use to render, which is 4 bytes per 
pixel. (You can have a 1Kb PNG which has a decompressed size which would 
require many gigabytes decompressed, for example).


Filename referenced images are decompressed and cached on use - the size 
of the cache is determined by the 'imageCacheLimit' global property, and 
its current usage is the 'imageCacheUsage' property - both are in bytes.


If your image cache is too small, then there will be a 'bump' whenever 
an image needs to be decompressed - you can ensure images are in the 
cache (assuming the cache is large enough) by using the 'prepare image' 
command.


The engine understands @ suffixes to image filenames (before the 
extension!), which allow you to provide different sizes of images 
depending on the device pixel resolution of the device. For example, if 
you have lots of images which have been prepared for retina devices, 
then they will be being scaled down on lower resolution devices for no 
real gain, and will be taking more memory than need be on such devices - 
take a look at the (image) filename property in the dictionary which 
explains how that works.


By default the engine maps 1 pixel in LiveCode space to 1 logical pixel 
in device space. A (original!) retina device will have 2 device pixels 
to 1 logical pixel, whereas a non-retina device will have 1 device pixel 
to 1 logical pixel. For retina devices you generally want images of 2x 
the horz and vert size compared to non-retina to ensure maximum display 
fidelity.


So one thing to check is that all your images are not 'oversized' - i.e. 
they are the exact size needed to fit the pixel rect of the objects 
using them in LiveCode. Then provide @2x ones for higher resolution 
devices. Assuming your images are currently 'oversized' to ensure good 
display on high-res devices, this will save you 75% of the in-memory 
footprint when running on a lower-res device (i.e. not retina).


In terms of accelerated rendering...

The cache of 'tiles' used in acceleratedRendering is per-stack, and is 
reset on every card change. The cache is only 'in-memory' when the stack 
is opened. On mobile it is possible for more than one stack to be 
opened, they stack from most recently opened to least recently opened. 
So, in general, it is probably better to explicitly close stacks you are 
no longer using. Using the 'go in window' form of the go command (IIRC) 
does this for you - i.e. closes the old and opens the new, and is 
probably the most efficient means to move between stacks on mobile.


The amount of memory which is used by acceleratedRendering (on any one 
stack) is always the compositorCacheLimit of the stack. If the stack 
requires more tiles to render than the cache-limit allows, 
acceleratedRendering will not be used, and the engine will fall back to 
normal rasterization.


On mobile, if you are using OpenGL modes of acceleratedRendering, then 
(IIRC) the cache is actually the GPU RAM which is used, and not 'normal' 
RAM (if there is a difference these days with more flexible memory 
busses!). However, there is an overhead in generating the tiles - but 
that is only transient and is never more than the pixel size of the 
stack at device resolution (e.g. for a 800*600 stack non-retina - it 
would require a maximum temporary buffer of 800*600*4 bytes).


In terms of memory, then the above two things are pretty much the 
largest 'memory hog' of any application - unless you are loading large 
amounts of data into memory (which I don't think you would be in the 
case of your app - we're talking more like doing analysis of 100,000s of 
points of data) then any memory issues will likely be due to graphics.


Hope this helps!

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

On 12/30/17 2:44 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

I think we need to wait until HQ weighs in on my bug report. Regardless of the fact that it works 
on iOS and Oreo, one has to wonder how on earth we can close a stack which is set to destroy on 
close, turn acceleratedRendering to false (assume previously cached controls are  cleared); open a 
new stack and*still*  see the old stack behind the new, one, as if they two are still fighting for 
the pixel map…. even if the old one "loses" on iOS and Oreo…and the new stack 
"wins" the display.. .the old one could still be in the heap.


This could be a redraw issue rather than an open stack, but see what HQ 
says. I know that pixels outside the card area aren't redrawn on mobile, 
this could be related.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

Reading this in depth. yes, reallocation of bit map space is beyond the 
developer's realm… 

I spotted this too… RGB 565… 

Anyone using this and getting smaller files sizes ver current jpgs? I'm not 
seeing this as an option in Photoshop on Mac.



 How we reduced our Android app’s memory footprint by 50%



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

This looks very useful . 

I think we need to wait until HQ weighs in on my bug report. Regardless of the 
fact that it works on iOS and Oreo, one has to wonder how on earth we can close 
a stack which is set to destroy on close, turn acceleratedRendering to false 
(assume previously cached controls are  cleared); open a new stack and *still* 
see the old stack behind the new, one, as if they two are still fighting for 
the pixel map…. even if the old one "loses" on iOS and Oreo…and the new stack 
"wins" the display.. .the old one could still be in the heap.

So if this indicates a failure at garbage collection (my very un-informed 
guess) the app will run out of RAM very fast. So however hard we work to 
optimize any script…it will get us nothing, 5 minutes into using the app, 
moving from stack to stack, crash is imminent.

That said the new script profiler in 9 is awesome (when it runs…often I start 
it, stop it and it is empty…)

e.g. I found a repeat loop that keeps setting the left of a large parent group  
being build up from copying child groups run time…everytime a child group is 
added (100 times) and this one task of setting the left of group "item-list" to 
0 on every loop, even with lockscreen on, was taking 80% of the time needed to 
do the job. it was this developer's (not me) attempt to overcome the challenge 
issue of the coords/ ect of the group constantly being lost despite use of 

on layoutGroup pNum
   -- general list group stuff
   set the lockupdates of group "item list" to true
   set the lockupdates of me to true

the coords still keep getting lost…and require resetting the parent group so 
that 0,0, us actually "known" to the subgroup being appended as a "row" at the 
bottom.  

Me thinks we are working too hard at this one… and I'm noodling a refactor… it 
will be interesting if DataGrid2 represents a "leap" forward for this kind of 
graphically complex list group.  I have stayed away from it as more complex 
than needed… OTOH if DataGrid2 will be more performant, then we should use it.

Meanwhile, other operations, like fetch data from the database, setting props 
on the next-copied subgroup  etc. which I thought (wrongly) would be costly 
were all profiling in at 1 millisecond.. So this new tool is going to be really 
helpful … I just have to figure out why it so often appear blank after running 
scripts.






 Richard Gaskin wrote:

While looking for one of the URLs I included in my last post, I came 
across this:

How we reduced our Android app’s memory footprint by 50%



I have no idea if those strategies would make sense in LC's internals, 
or whether LC is already doing some of that sort of bitmap reuse.  But 
an interesting read just the same.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

Worth reading just to find out about the 57 MB app memory limit.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On December 29, 2017 9:54:34 PM Richard Gaskin via use-livecode 
 wrote:



While looking for one of the URLs I included in my last post, I came
across this:

How we reduced our Android app’s memory footprint by 50%


I have no idea if those strategies would make sense in LC's internals,
or whether LC is already doing some of that sort of bitmap reuse.  But
an interesting read just the same.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Richard Gaskin via use-livecode]

While looking for one of the URLs I included in my last post, I came 
across this:


   How we reduced our Android app’s memory footprint by 50%


I have no idea if those strategies would make sense in LC's internals, 
or whether LC is already doing some of that sort of bitmap reuse.  But 
an interesting read just the same.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> I would not even know where to start to understand what to what extent
> an app is overloading RAM on Android.  How do we measure this stuff.

Settings -> Developer Options -> Running services

That brings up a simple list of processes in memory, noting among other 
things the memory usage of each.


It's more specific than the list in the non-dev option in Settings -> 
Memory -> Memory used by apps.


If you need insanely detailed deep info, consider turning on the Power 
Menu Bug Reports option:

https://tamingthedroid.com/power-menu-bug-reports

There are also many third-party apps for getting process details, e.g.:
https://play.google.com/store/apps/details?id=com.p_soft.sysmon=en

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

I certainly did not mean to imply by "only" that pointed to the market share of 
phones with 1 GB ram.

OT: I was just reading Quora about how US overwhelming Germany with sheer 
numbers of tanks and jets that had much lower specs than German made 
tanks/planes. But we won on our sheer industrial power to produce numbers.  

so that's happening in Asia… but it's intereseting to see in your graph  that 
in India 2GB phones are approaching 1 GB phones..and other indicators for my 
target markey which are middle class youth primarily.. would put them in the 
2-3GB phone market… but even this one is complaining about the app on Galaxy 
with 3 GB of RAM (Jacque he was not referring to his own phone but to others) 
FYI I mentioned this before… it's being driven by demonitization. every farmer 
and street seller needs a $20.00 smart phone just to seel his fish on the 
street. But that's not our audience.

and the article you linked to puts the "blame" (if you will), on the OS… 

"While 2GB of RAM is enough for iOS to work smoothly, Android devices need more 
memory."

Musings: 

So that make one wonder, how far should we expect LiveCode to optimize (and 
possibly compromise) it's stack, to work on Android?  Versus pushing for better 
displays transitions -- see Scott Rossi's incredioble "looking forward" on LC 
Global… the LC engine is really need to going to grow, change scale to stay in 
the game, easy rounded corners everywhere,, i.e. engine features that support 
our drive for more and better content. 

We don't built utilities here, we build "culture" so I have to ask myself if we 
want to move forward creating our little "disney world on a phone" or if we 
need to rachet back to "simple caddy shack to hold a few clubs and golf balls." 
Frankly the latter is just not an option, our brains/production don't track 
like that at all.

End Musings:  back to ground:

I would not even know where to start to understand what to what extent an app 
is overloading RAM on Android.  How do we measure this stuff. At least on a 
linux web server I have TOP and easy I/O tools to tell us exactly what is 
happening. We need this for LC, ideally without our having to reinvent a 
monitoriing system.

I suppose the new script profiler should help us? but I don't really know where 
to begin.   

At least, dealing with a lot internet connection is a "no brainer" but bigger 
questions leave us in the dark

Data Grid 2 versus a field, vs a group with sub-groups with many child object, 
built dynamically on the fly from a mySQL dbase. Does it make more sense to 
cache the data as an LC array vs MySql Query? and how do you measure what is 
going on… What is the most efficient way to fetch 150 k Plain text and style it 
on the fly, for display. (H1 heads,  lists, bold, space before and after… etc) 
in a field? 

I feeding everything to the support team on this round… so they are getting to 
see it all. 

Stay tuned… now back to building more content and studying out the script 
profiler….









 

On 12/29/17, 12:30 PM, "use-livecode on behalf of Richard Gaskin via 
use-livecode"  wrote:

> To what extent we can realistically fit this app onto a phone with
> only 1GB of RAM… I don't know.

"Only"?  That's a lot of phones




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> To what extent we can realistically fit this app onto a phone with
> only 1GB of RAM… I don't know.

"Only"?  That's a lot of phones



--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

On 12/29/17 2:25 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

To what extent we can realistically fit this app onto a phone with only 1GB of 
RAM… I don't know.


So it's a memory problem after all. Google is making/has made a 
slimmed-down version of Android specifically for India and other areas 
with minimal bandwidth and phone specs, so it's a recognized issue. You 
may just have to limit the user base to qualifying devices.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

FYI here is Aravind's from Kerala comments today.

To what extent we can realistically fit this app onto a phone with only 1GB of 
RAM… I don't know.

Perhaps this is useful for other Android developers looking for a broad base in 
Asia, although this may be all "old news" to most of you… here it is.

one issue we have is: we cannot overlay any other controls over the browser 
widget.. so even if we can't use TSNet for this but monitor the 
browserDocument* msgs… we still need a way to communicate on the UI… I'll need 
to fiddle with that.. I suppose the only option is to "raise a toast" from the 
bottom while at the same dynamically shrinking the height of the browser 
widget.  Any ideas there?

Meanwhile, another app we have that is HTML five, he says "runs fine" but it 
never fetches content from the web.


Device (my Samsung Galaxy A7)  is using an internet connection(3G) which have a 
practical download at a maximum rate of 300kb/s(but speed test shows 2mb/s 
download speed). but sometimes during peak time the speed drastically reduces. 

The app may be set for an ideal condition. 

suggestion:  A message window in between the request and displaying download 
content showing "Downloading please wait". 
If net is slow , allow to abort by giving a message "Slow Internet, will take 
more time, Please close any other app(if any) using internet or abort." give 
buttons "wait" and "abort".
if net is fast enough, message won't be seen.

so the app will have better control and userfrienliness.

More over here there are new phones with 1Gb ram. so we need to optimise the 
app. 
The app must sense the screen resolution(seems only less than 10 standard 
resolutions). and usually all other parameters are relative to that. there are 
certain rare exceptions also. Another is three Ram options (1,2 and 3 or more).
In apple there is only 5 iphones(4,5,6,7,8). 
SivsSiva is a great app and hope it should reach the masses, especially in 
India.

see the spec of this new phone with Oreo OS(about Rs.7000/-) 
https://www.gsmarena.com/nokia_2-8513.php

 Samsung A7(exynos) may be slower then MotoG4 plus(snapdragon). Or May differ 
in some other specs.



 

On 12/28/17, 4:13 PM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

That's a different model than Google gave me. This one has better specs. 
I'm not sure how the CPU compares to the Snapdragon but in general it seems 
sufficient.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

That's a different model than Google gave me. This one has better specs. 
I'm not sure how the CPU compares to the Snapdragon but in general it seems 
sufficient.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On December 28, 2017 7:05:08 PM Sannyasin Brahmanathaswami via use-livecode 
 wrote:



This is the Galaxy Samung A7 2017

http://www.samsung.com/in/smartphones/galaxy-a7-2017-sm-a720f/SM-A720FZDDINS/

pertainly doesn't seem under powered…how is a "2017" two years old?... do 
they just pump out the same device and slap new date on it? but the 
hardward/components are the same as they were?



On 12/28/17, 1:22 PM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:


On 12/28/17 4:50 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>So, "weird" … Galaxy Samsung  A7 in India running Android version 7.0… --- 
problems

>Moto G4 Plus, London Android 7 -- users says it works just fine

The Moto is 2 years newer, has a faster CPU, and double or triple the
memory depending on configuration. That's got to help.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

This is the Galaxy Samung A7 2017 

http://www.samsung.com/in/smartphones/galaxy-a7-2017-sm-a720f/SM-A720FZDDINS/

pertainly doesn't seem under powered…how is a "2017" two years old?... do they 
just pump out the same device and slap new date on it? but the 
hardward/components are the same as they were?
 

On 12/28/17, 1:22 PM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

On 12/28/17 4:50 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>So, "weird" … Galaxy Samsung  A7 in India running Android version 7.0… --- 
problems
>Moto G4 Plus, London Android 7 -- users says it works just fine

The Moto is 2 years newer, has a faster CPU, and double or triple the 
memory depending on configuration. That's got to help.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

On 12/28/17 4:50 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

So, "weird" … Galaxy Samsung  A7 in India running Android version 7.0… --- 
problems

Moto G4 Plus, London Android 7 -- users says it works just fine


The Moto is 2 years newer, has a faster CPU, and double or triple the 
memory depending on configuration. That's got to help.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

Great pointer's Andy, I will try those browser checks… TS Net does not interact 
with either the browser or a mobile play that streams audio, so we are "on our 
own… " to Monitor those.


Meanwhile this is from London, happy new user

---
"So far so good. No problems, everything running smoothly. … I am on a Moto G4 
plus. Android version 7.0"


So, "weird" … Galaxy Samsung  A7 in India running Android version 7.0… --- 
problems

Moto G4 Plus, London Android 7 -- users says it works just fine

??  Hmm, yes, this could be related to the browser because our London "market" 
has very high speed access to our content which is served from Cloud Flare./ 
not so in Cochin… 

  wrote:

Also are you making sure the destroyStack to true. 
This should be automatically done but there is no harm in forcing it.

set the destroyStack of this stack to true

It might also be useful to monitor these events in the browser widget
and set a timer between the browserDocumentLoadBegin and
browserDocumentLoadComplete to see if there is a bottle neck?

browserDocumentLoadBegin pUrl
browserDocumentLoadComplete pUrl
browserDocumentLoadFailed pUrl, pError



-
Andy Piddock 


My software never has bugs. It just develops random features. 

TinyIDE  a Free alternative minimalist IDE Plugin for LiveCode 


Script editor Themer for LC http://2108.co.uk  

PointandSee is a FREE simple but full featured under cursor colour picker / 
finder.
http://www.pointandsee.co.uk  - made with LiveCode
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[AndyP via use-livecode]

Also are you making sure the destroyStack to true. 
This should be automatically done but there is no harm in forcing it.

set the destroyStack of this stack to true

It might also be useful to monitor these events in the browser widget
and set a timer between the browserDocumentLoadBegin and
browserDocumentLoadComplete to see if there is a bottle neck?

browserDocumentLoadBegin pUrl
browserDocumentLoadComplete pUrl
browserDocumentLoadFailed pUrl, pError



-
Andy Piddock 


My software never has bugs. It just develops random features. 

TinyIDE  a Free alternative minimalist IDE Plugin for LiveCode 


Script editor Themer for LC http://2108.co.uk  

PointandSee is a FREE simple but full featured under cursor colour picker / 
finder.
http://www.pointandsee.co.uk  - made with LiveCode
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[AndyP via use-livecode]

I don't think its such an issue targeting the latest Android versions as
Google's new developer rules as August 2018 will require that apps will be
targeted at the last latest build.

http://developers.googleblog.com/2017/12/improving-app-security-and-performance.html

  





-
Andy Piddock 


My software never has bugs. It just develops random features. 

TinyIDE  a Free alternative minimalist IDE Plugin for LiveCode 


Script editor Themer for LC http://2108.co.uk  

PointandSee is a FREE simple but full featured under cursor colour picker / 
finder.
http://www.pointandsee.co.uk  - made with LiveCode
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

I am going thru Aravind's reports. His phone is top of the line Android… 
Samsung Galaxy A7 (3GB RAM)   7.0 Nougat, 

It appears that 8.1.9 RC 1 did not fix all the Android rendering issues… yes, 
the problem of leaving the app via home or app switch and coming back to the 
app, yes, that is solved, but there is something else going on here:

see:  http://quality.livecode.com/show_bug.cgi?id=20810

check out his screen shots.

http://wiki.hindu.org/uploads/20171227_095851.jpg
http://wiki.hindu.org/uploads/20171227_095835.jpg

what appears "behind" is a screen from previous stacks that were opened and 
closed.

 our navigation library is pretty straight forward, when it gets to this point
---
if oStackName <> empty then # this is not the first run boot of portal
  deleteAllMobileControls # will destroy all except audioPlayer
  set the accelereratedRendering of the topstack to false 
end if
 
   go  cardOrStackObject 
 # e.g   go Stack "b"  "gems" (or whatever this string)  go card 3 of "gems"   
whatever it is
# this stack might turn on acceleratedRendering in it's openCard Handler… 

   wait 100 milliseconds with messages  

   close stack oStackName
# closed ! but not gone… a visual "rep" of this stack is still retained, 
# and not only that, possibly many others of previously closed stacks

   wait 100 milliseconds with messages  
---
that's not mysterious… we know from previous tests that the wait 100 
milliseconds is mission critical. Without those, even on my Pixel.. we get 
serious rendering issues.

So… guessing that entire screen representation(s) of closed stacks are 
appearing behind the newly opened surprise.livecode stack… and not only that, 
this could be images of the screens of different stacks that were opened 
several steps back… so only Ganesha knows how many representations of the 
screen(s) that have gone by and closed by our code are still being retained in 
RAM until the app dies. or some kind of caching is happening that needs 
flushing… At least that's how it looks here.  

BR









 

 

On 12/27/17, 5:37 PM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

If you limit your user base to Android 8.1 almost no one can use it. Right 
now it has a very tiny user base, I think only Pixel users have that 
version. It was just pushed to Pixels a little while ago. A whole lot of 
devices are still waiting for Android 7.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

If you limit your user base to Android 8.1 almost no one can use it. Right 
now it has a very tiny user base, I think only Pixel users have that 
version. It was just pushed to Pixels a little while ago. A whole lot of 
devices are still waiting for Android 7.



On December 27, 2017 8:49:02 PM Sannyasin Brahmanathaswami via use-livecode 
 wrote:


… So, another route is: take Aravind's recommendation and set the hardware 
requirements to 8.1 "Requires Oreo" and let the rest of the Android world 
wait/catch up… Not ideal, but with Google pushing so hard now on security 
and deadlines for new apps to run on the latest Android… it won't be long…


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

@ Andy (cc support) 

Yes, I used tinyPng I have paid for their 50 image at a time option, awesome 
tool, I think we will get a site license of photoshop plug in…

The home card(s) (navigation "portals) on the app are one big parent scrolling 
parent group with some subgroups. max 8 "rows) with the mobile scroller set to 
scroll the group.

Of course a lot of libs have been put into memory with "start using" so besides 
the ~650K of images on the card there's another X number of lines of code.

But my gut says: something has to be wrong in the engine… 

these crashes are coming from a Samsung Galaxy A7 , 2017 running 7.0

Android 6.0.1 (Marshmallow), upgradable to 7.0 (Nougat)
Chipset Exynos 7880 Octa
CPU Octa-core 1.9 GHz Cortex-A53
GPU Mali-T830MP3
Memory  Card slot   microSD, up to 256 GB (dedicated slot)
Internal32 GB, 3 GB RAM
Camera  Primary 16 MP (f/1.9, 27mm), autofocus, LED flash, check quality
FeaturesGeo-tagging, touch focus, face detection, panorama, HDR
Video   1080p@30fps, check quality
Secondary   16 MP, f/1.9, 1080p
 
The beta tester in Kerala who has the above phone is sending me detailed 
reports on crash scenarios, and thanks to your tip, videos also.

Each stack we put into memory, after removing/closing the previous one, has 
very different requirements. We swap in and out a background graphic for almost 
all stacks, but these are less than 120K each for the whole card backgrounds…

One issue seems to be with the browser widget and low internet bandwidth… 
causing crashes…on iOS we just see a white screen "like forever…." 

Of course we can do a better job (I tried by failed on first attempt) to use TS 
Net to monitor and help with that area… connectivity… but still  I just find it 
hard to believe that the stacks + images + code  we are deploying are 
overloading the hardware on a device with this much horsepower. 

I'll need to do a deep dive into Aravind's reports and see if we can pin point 
more specifically what is happening. I just replicated a crash on iOS where the 
link to open a card with the browser widget caused a crash on iOS also… but 
can't reproduce it now…but I do smell a "little mouse" down around webKit 
somewhere… 

but I can "hammer" like a teenager(amazing to watch how fast these kids tap and 
swipe on their devices) on my Pixel and the app never dies… So, another route 
is: take Aravind's recommendation and set the hardware requirements to 8.1 
"Requires Oreo" and let the rest of the Android world wait/catch up… Not ideal, 
but with Google pushing so hard now on security and deadlines for new apps to 
run on the latest Android… it won't be long… 

BR



On 12/26/17, 11:57 PM, "use-livecode on behalf of AndyP via use-livecode" 
 wrote:

Do you compress your png images?

If not give this a try. 

https://tinypng.com   



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

7 installs end of day one..yesterday 
End of today, up to 21

But with 61 crashes already! Yikes.

So I expect it will get hit pretty hard... I put signs up around here and we 
are getting about 400 visitors a day… I expect about 50% of them are on Android…

I'll have to keep the promotion quiet until we see if we can fix some of these

Google's Crash reporting is pretty awesome

43 crashes on Android 7.0  
8 crashes on Android 8.1 (probably my own phone - pixel)
3 crashes in Android 7.1


signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
librevandroid.so

Ouch…. 

I put in a support call to HQ……  

On 12/27/17, 10:39 AM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

Besides the memory footprint, there could be stress on the CPU when 
running scripts that aren't tightly optimized. You might see what can be 
pared down there. Big job, I know, with a project this large.

On 12/26/17 11:04 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>Our new SivaSiva app expects a lot of horse power. If we want to optimize 
for smaller devices, I'm not sure where to begin.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[J. Landman Gay via use-livecode]

Besides the memory footprint, there could be stress on the CPU when 
running scripts that aren't tightly optimized. You might see what can be 
pared down there. Big job, I know, with a project this large.


On 12/26/17 11:04 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

Our new SivaSiva app expects a lot of horse power. If we want to optimize for 
smaller devices, I'm not sure where to begin.



--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Optimizing for small Android devices

[AndyP via use-livecode]

Do you compress your png images?

If not give this a try. 

https://tinypng.com   



-
Andy Piddock 


My software never has bugs. It just develops random features. 

TinyIDE  a Free alternative minimalist IDE Plugin for LiveCode 


Script editor Themer for LC http://2108.co.uk  

PointandSee is a FREE simple but full featured under cursor colour picker / 
finder.
http://www.pointandsee.co.uk  - made with LiveCode
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Optimizing for small Android devices

[Sannyasin Brahmanathaswami via use-livecode]

Our new SivaSiva app expects a lot of horse power. If we want to optimize for 
smaller devices, I'm not sure where to begin.

We can't really shrink graphics below 55k png for small thumbs… so if we have 8 
of these on a card and a hero image around 200 K… we are talking about ~700K 
image data on a single card + fields, buttons and other controls..

It this *really* too much for a small phone?

Putting the question another way: what exactly starts causing slow down's in 
terms of RAM/ScreenResolution/CPU.

I would not even know where to begin to get capacity/capability "measurements" 
for our code to have so that we can work on some AI algorithms for optimizing 
behavior on the fly for smaller devices…

Any thoughts in this area?

BR



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode