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@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@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
