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

Reply via email to