Launch vs Set in widget

[J. Landman Gay]

This is long, so most of you will probably want to skip it.

On 9/1/19 6:48 AM, Mark Waddingham via use-livecode wrote:
> 
> Hmmm - you say 'on your Pixel' - have you observed the behavior on other
> devices, or indeed other Pixels? (It might be worth creating a Pixel
> emulator which will be in factory state and see if you get the same
> behavior).

I'll try it on my ancient Samsung S5, but it may very well be my Pixel. 
It won't always load an entire file into the browser widget either, but 
different testers using a Pixel, Pixel 2 and a Moto G4 did fine. If it's 
just my phone that would be good. Wouldn't an emulator use the GPU on my 
Mac, where everything works fine in the IDE?

The browser is loading all its HTML files from the Documents folder on 
the device if that matters, there are no internet URLs.

> 
> The mobileCreate and browser widget use the same system classes so I'd
> be surprised if it made any difference switching - especially as the issue
> sounds like it is to do with navigating between pages in the widget
> which is the concern of the system webview class, rather than the engine.

Thanks, that will save me rewriting the scripts to test it.

> 
> One thing which might be instructive is to capture the logcat whilst you
> run your app and then cause it to become 'not responding' - such situations
> are usually accompanied by quite a lot of log lines, especially if some
> sort of internal exception is occurring.

If I can, I'll try it. I have to look up my notes.

> 
>> I badly need to be able to respond to the backKey too, but apparently
>> that's not possible. The widget eats it. As for acceleratedRendering,
>> it's broken. I had to turn it off completely.
> 
> Looking at the engine code if you are using the browser widget then you
> should be getting the 'backKey' message as normal - if you are using
> mobileCreate browser, then *that* would eat it. Do you have a mobileCreate
> "browser" instance lurking somewhere still by accident?

I'm sure there is no other browser instance anywhere. The stack was 
created with the widget in place and I haven't put in any code yet for 
mobileCreate. My goal is to use the backKey only for stack navigation, 
while still allowing the user to navigate when clicking the links in the 
browser content. Actually, I wouldn't care if the backKey did traverse 
the history as long as the card gets the message when the history is 
exhausted.

Links frequently need to load a new file from disk. Right now, clicking 
browser links works a few times, then the entire app freezes and the 
only recourse is to quit when the "not responding" message appears.

> 
> [ I might have read the engine code wrong though... ]
> 
> When you say 'acceleratedRendering' is broken, can you elaborate?
> 
> FWIW, we've been using acceleratedRendering alongside browser widgets
> internally on Android extensively and haven't seen any issues...

I was a bit vague. The acceleratedRendering issues occur throughout, and 
do not occur when acceleratedRendering is completely turned off. There 
is a mainstack with two substacks, one of which has the browser widget, 
but acceleratedRendering redraws are bad everywhere. Originally I set 
ACR in preOpenStack on the 3-card mainstack and in both substacks. It 
seems the browser widget doesn't need that, so I've removed ACR from 
that stack. The mainstack has a login card, a TOC (Table of Contents) 
card, and the main content card. All navigation uses visual effects to 
emulate swiping. FullscreenMode is "showAll". With ACR on in preOpenStack:

1. Going from login to TOC is fine.

2. Going from TOC to content is fine the first time. Going back to the 
TOC is okay, but returning to the content causes a kind of double 
display hiccup; you see the old content, then the new content, then the 
visual effect happens and the new content is there. I showed this to Ian 
at the conference and he said my script should work, but I haven't been 
able to create a test stack to report it since it requires the whole app 
world to function.

3. The user can change "cards" by swiping, the screen is locked, content 
updated from a script-local array, and unlocked with "visual effect in 
rect". Sometimes it works great. Other times there is random junk drawn 
(my testers see this, they described it as "diagonal lines.") On my 
Pixel, the entire card goes multicolor chaotic garbage. My testers said 
the "lines" only last a moment and then the actual content appears. On 
my Pixel, the card never does appear, the random garbage doesn't respond 
to taps, and I need to quit and restart the app.

4. Going from the browser stack back to the mainstack causes the browser 
widget to remain on screen, obscuring the destination card. I don't 
think it is really there, because tapping where a control should be 
would redraw the content and the phantom browser disappears. I tried 
hiding the widget before leaving its stack but it would not hide.

To attempt to fix it: I removed ACR from the preOpenStack and put it 
into the handler that creates native scrollers, since that's the only 
place I really need it. ACR is turned off again when the mobile controls 
are deleted which always happens before card or content changes. With 
this change:

5. The double-display when leaving the TOC, and the random chaos on my 
screen is gone, but I see a black screen instead. It does not remain, so 
I am able to continue, but card changes almost always blink black.

6. The widget navigates normally as long as the freeze-up doesn't happen 
first and I tap the on-screen back arrow instead of the backKey. But if 
I tap the backKey while a file is loading into the widget (which takes a 
long time,) it goes back to the mainstack and the widget overlays the 
destination card as it did before.

I can't create bug-report stacks since everything depends on the whole 
app structure being in place. Maybe I'll send Panos the whole thing and 
ask him to wade through it.

None of this happens when ACR is not used at all, but my scrollers are 
jerky.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com