Artifacts on screen from closed stacks on Android

[Brian Milby]

Have you tried a blank background image on stack B to explicitly overwrite
the buffer for areas outside of the stack? That may help problem 1 but
probably won’t help problem 2.
On Sun, Jan 28, 2018 at 2:05 PM Sannyasin Brahmanathaswami via use-livecode
<use-livecode at lists.runrev.com> wrote:

> We are getting reports (and screen shot and screen videos) from some
> Android users that show artifacts from a previously opened Stack A, when
> opening Stack B
>
> where
>
> Stack A is explicitly closed and has both destroyStack and destroyWindow
> set to true.
>
> In the absence of being able to reproduce these residual closed-destroyed
> stack artifacts issues on my Pixel (and HQ can't either) I am wondering if
> there is some hack, that will not affect performance too much, to forcibly
> clear out the pixels of the previously opened stack?  Details below:
>
> There is bug report on this already
>
> http://quality.livecode.com/show_bug.cgi?id=20810
>
> You can see screen shots there from a Galaxy A7 (2017) running Nougat…
> this is not an underpowered phone..
>
> but it's hanging  under "Pending Followup" --  this was a mid-holiday
> report… so perhaps now that we are all "back at it" we ca work on this.
>
> Two examples are
>
> 1) least offensive scenario:
>
> Stack A may have a background image set 1028 X 1028… a lo-res image,
> centered so that regardless of the device width or height, using
> fullScreenMode, this background will fill..
>
> Then we open a stack that has no such background and is constrained to 414
> wide… if the device screen ration is a bit off then this will be pillar
> boxed… some stripes, left and right… and these are filled with the image of
> the previous stack A. Even Though Stack A, and it's window is destroyed.
>
> 2) worst case scenario
>
> Entire image map of Stack B is not fully rendered.. even get some bizarre
> tiles or squares with odd colors or image data from Stack A, and only one
> area of Stack B is rendered like some weird inlay or overlay on top of the
> pixel map of Stack A.
>
> Again, all stacks have their stack and window set to destroy and are
> explicitly closed after Stack B is opened. You must have a stack open and
> visible on Mobile or the app will crash, so that's why we leave Stack A
> open and only close it *after* Stack B is opened.
>
> I have no recipe for this, and so HQ is at a loss. we also don't see this
> on our Pixel. Though I think I did occasionally see #1 above, but never #2.
>
> I have yet to issue an update using "go in window" which Mark W. has
> recommended. But apparently we still need to explicitly close Stack A even
> if we "go  "Stack B" in window "Stack A"  and rather than issue this
> update, only to find it doesn't help.. I was fishing for a "clean up the
> video display ram" solution…
>
> And side question:
>
> What is the difference between destroyStack and destroyWindow. From the
> dictionary definitions, they appear to do the same thing, but we have them
> as separate props in the PI, so I presume they are not synonyms but have
> separate functions. Mute, because I set both to true for all stacks.. but
> still wondering the difference?
>
> BR
>
>
>
>
>
>
>
> Svasti Astu, Be Well
> Brahmanathaswami
> www.himalayanacademy.com<http://www.himalayanacademy.com> Get SivaSiva
> App Today--It's Free!
>
> iOS: https://itunes.apple.com/us/app/sivasiva/id1271260502?mt=8
> Android:
> https://play.google.com/store/apps/details?id=com.himalayanacademy.sivasiva
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode