Launch vs Set in widget
J. Landman Gay
jacque at hyperactivesw.com
Sun Sep 1 17:48:49 EDT 2019
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
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
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
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
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode