Hello Hongbo,
please excuse my late reply.
Thanks a lot for your suggestion! We've been able to launch the Cordova XWalk
WebView with exposed garbage collection by following the instructions in the
link you've provided.
While the app stayed alive longer with manual garbage collection it still
crashed consistently with the same error (Fatal signal 6 ... Audio Decoder).
When falling back to HTML audio tags instead of using WebAudio the app stops
crashing and runs stable.
So, you might be right with your suspicion that there is a bug in the native
audio module.
For now, we're glad to have a workaround.
Cheers,
Florian
Am 10. Juli 2014 bei 07:05:50, Min, Hongbo (hongbo....@intel.com) schrieb:
Florian,
I think it is no problem about the usage model of XWalkView according to your
description.
There is a way to trigger JS garbage collection by manual in Crosswalk. You can
follow the instructions [1] to use xwalk command line option when packaging
your app, the option to enable GC is as below:
--xwalk-command-line=’--js-flags="--expose-gc"’
Then you can call ‘gc()’ in you JS code to GC manually. Have a try, and if the
memory is still boating, I seriously suspect there is some memory leaking
happened in native modules, e.g. canvas (2d or 3d?), audio and websocket.
According to the bug XWALK-1993 and my simple experiment with canvas 2d +
iframe (no leaking I observed), it is very likely that audio module may be
problematic. You can try to disable webaudio in your app and examine the final
result to identify the root cause.
[1]
https://github.com/crosswalk-project/crosswalk-website/wiki/use-chromium-command-lines-in-your-apps-on-android
From: Florian Landerl [mailto:flor...@platogo.com]
Sent: Wednesday, July 9, 2014 11:35 PM
To: Min, Hongbo; crosswalk-help@lists.crosswalk-project.org
Subject: RE: [Crosswalk-help] Transparent WebView
Thanks for you assistance, Hongbo.
We tried creating examples to reproduce the issue we're experiencing but so far
we haven't been able to do so...
Unfortunately, we are not free to share the canvas games where it _always_
happens. The games are quite heavy on graphical assets and use HTML5 APIs such
as canvas, webaudio, websockets, ... In the web inspector's memory timeline a
game takes about 30Mb of RAM. Games can be launched (& quitted/removed)
multiple times before the app definitely dies. We thought about manually
triggering garbage collection but haven't found a way to do so.
In tests we’ve been able to allocate a lot more memory (>500Mb) than is ever
used by our app before crashing. Maybe the reason is not the RAM but something
else like full graphics memory, audio issues, ...? So far we haven't been able
to pinpoint the exact reason.
Here is part of our stacktrace (complete crashlogs are available in this bug
report: https://crosswalk-project.org/jira/browse/XWALK-1993):
F/libc ( 7959): Fatal signal 6 (SIGABRT) at 0x00001f17 (code=-6), thread
11523 (Audio Decoder)
I/DEBUG ( 176): *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
***
I/DEBUG ( 176): Build fingerprint:
'google/razor/flo:4.4.4/KTU84P/1227136:user/release-keys'
I/DEBUG ( 176): Revision: '0'
I/DEBUG ( 176): pid: 7959, tid: 11523, name: Audio Decoder >>> [package] <<<
I/DEBUG ( 176): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
I/DEBUG ( 176): r0 00000000 r1 00002d03 r2 00000006 r3 00000000
Regarding your questions:
1) we remove the iframe DOM node. Here's the exact code we're using:
var game = document.getElementById("game");
var frameDoc = game.contentDocument || game.contentWindow.document;
frameDoc.removeChild(frameDoc.documentElement);
game.setAttribute("src", "about:blank");
// game DOM node is removed by FB React; same happens when manually
creating/removing the iframe node
2) we only have one XWalkView in our Cordova project
3) we have a single page javascript app, crash happens without using the back
button or resuming the app
We appreciate any ideas because this is a real showstopper for us.
Cheers,
Florian
Am 09. Juli 2014 bei 08:27:11, Min, Hongbo (hongbo....@intel.com) schrieb:
Great problem description, thanks!
Well, the transparent webview is not supported by XWalk yet.
As you mentioned, it would take a long time to reclaim the memory after iframe
is removed, it is not beyond my expectation since the memory reclaim happened
in DOM tree depends on the javascript GC, we cannot anticipate the timing when
it should be reclaimed.
I have a simple experiment with XWalkView to add/remove iframe (containing a
canvas game) again and again, actually I don’t find the memory bloats, and the
app runs well. So I have 3 questions about your use case:
1. How do you remove iframe? By document.removeChild, visibility:hidden or
display:none?
2. Is it only one XWalkView created in your case that would crash later?
3. Do you press ‘back’ button and resume it back before the app gets
crashed?
Thanks…Hongbo
From: Florian Landerl [mailto:flor...@platogo.com]
Sent: Tuesday, July 8, 2014 6:57 PM
To: Min, Hongbo; crosswalk-help@lists.crosswalk-project.org
Subject: RE: [Crosswalk-help] Transparent WebView
Hello Hongbo,
thanks for your answer!
A transparent webview for our needs is exactly as you described: elements
(text, images) should be rendered normally but the body’s background color
should be transparent instead of white. This used to be possible but that
behaviour seems to be broken for quite some time. We found this bugreport from
2011: https://code.google.com/p/android/issues/detail?id=14749
Actually using a transparent webview was an attempted workaround for a
completely different issue we’re experiencing: we load 3rd party content
(canvas games) inside an iframe and show custom UI partially above the game.
Problem is that it takes a long time until the memory is reclaimed after the
iframe has been removed. We do not see this behaviour in normal (non XWalk)
webviews. Our idea was to load the canvas games in another webview to have that
memory isolated & taken care of separately.
So our main problem is that the app will crash after some time because the
memory is not properly/quickly enough freed. We haven’t found why this happens
but we’ll continue to investigate. Do you have any idea what causes the issue
with the iframe?
Thanks,
Florian
Am 08. Juli 2014 bei 03:16:08, Min, Hongbo (hongbo....@intel.com) schrieb:
Hi Florian,
setAlpha will actually hide the whole view visually. I am not sure what is the
right behavior of transparent webview. Would it only render text/image in the
page but with transparent background color instead of white color by default?
If so, I am afraid the current XWalkView cannot do that since the background
color is controlled by the renderer engine which doesn’t support transparent
color rendering, there is no way to change its background color by Android SDK
after the rendering is completed for a web page.
It would be appreciated if you could describe what the overlay webview looks
like and what the transparent background color is in your use case. Thanks.
Hongbo
From: Florian Landerl [mailto:flor...@platogo.com]
Sent: Monday, July 7, 2014 11:14 PM
To: Min, Hongbo; crosswalk-help@lists.crosswalk-project.org
Subject: RE: [Crosswalk-help] Transparent WebView
Hello Hongbo,
thanks for your suggestion. Apparently, there are several limitations with the
default SurfaceView (stacking views is not possible/advised). I already tried
enabling ANIMATABLE_XWALK_VIEW ever since I came across the following article
earlier today:
https://github.com/crosswalk-project/crosswalk-website/wiki/Android-SurfaceView-vs-TextureView
setAlpha() now indeed works. However, setting the opacity is not what I’m
looking for. We need to have a transparent background color in order to use the
webview as an overlay. Neither setBackgroundColor(Color.TRANSPARENT),
setBackgroundDrawable(null) nor setBackgroundResource(0) has any effect, even
when XWalkView is using a TextureView.
Is there anything obvious I’m missing?
Thanks,
Florian
Am 07. Juli 2014 bei 16:44:00, Min, Hongbo (hongbo....@intel.com) schrieb:
Florian,
You may have a try to enable animitable XWalkView, the setAlpha would work on
an animitable XWalkView. See
https://crosswalk-project.org/#wiki/Android-SurfaceView-vs-TextureView about
different backend for XWalkView, and
https://crosswalk-project.org/apis/embeddingapidocs/reference/org/xwalk/core/XWalkPreferences.html#ANIMATABLE_XWALK_VIEW
for how to enable animitable XWalkView. Hope it can work for you.
From: Florian Landerl [mailto:flor...@platogo.com]
Sent: Monday, July 7, 2014 5:54 PM
To: Min, Hongbo; crosswalk-help@lists.crosswalk-project.org
Subject: RE: [Crosswalk-help] Transparent WebView
Thanks for your reply, Hongbo.
Unfortunately, calling setAlpha() does not make any difference. Also,
setAlpha() would not yield the result we’re looking for: we need the background
color of the Crosswalk Cordova webview to be transparent. The Cordova webview
should act as some kind of overlay above the other webview.
We tried all of the following but none shows any effect:
* webView.setBackgroundColor(Color.TRANSPARENT);
* webView.setBackgroundDrawable(null);
* webView.setBackgroundResource(0);
Cheers,
Florian
Am 07. Juli 2014 bei 09:24:03, Min, Hongbo (hongbo....@intel.com) schrieb:
Hi, Florian
Does setAlpha on XWalk webview work for you?
Regards
Hongbo
________________________________
From: Crosswalk-help [crosswalk-help-boun...@lists.crosswalk-project.org] on
behalf of Florian Landerl [flor...@platogo.com]
Sent: Monday, July 07, 2014 5:39 AM
To: crosswalk-help@lists.crosswalk-project.org
Subject: [Crosswalk-help] Transparent WebView
Hello everyone,
is it possible to have a transparent Crosswalk webview?
In our Cordova project with XWalk webview we want to add an additional XWalk
based webview below the main Cordova view. We managed to create the second
webview but we've found no option so far to make the main webview transparent.
Is this possible at all?
Any help is greatly appreciated.
Thanks in advance!
Cheers,
Florian_______________________________________________
Crosswalk-help mailing list
Crosswalk-help@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-help
