WebViewGadget limitations and data transfer

[Kukulkan]

Hi. I plan to utilize the WebViewGadget in a cross platform app to do GUI and WebAssembly processing inside. For this, I need to transfer binary data into and out from the WebViewGadget.

I currenty do using base64 encoded strings, but I wonder if there are limits and better options?

In detail:

• are there limits for BindWebViewCallback function parameter JsonParameters$ size?
• are there limits for WebViewExecuteScript function parameter JavaScript$ size?

Can I also put and get binary data directly, without the way through JSON encoder/decoder or string functions with base64 and unicode overhead? Ideally I would submit a memory pointer and size to receive a ByteArray in JS and submit a ByteArray to receive memory pointer and size in PB? Is that possible?

I talk about sizes up to 250MB, which is the minimum I need to support. With base64 and string conversion, it needs 2.6 times the amount of memory:

Code: Select all

; memory consumption test
size.i = 1000
*mem = AllocateMemory(size.i)
; fill with random stuff
For x.i = 0 To size.i - 1
  PokeB(*mem + x.i, Random(255, 0))
Next

b64.s = Base64Encoder(*mem, size.i)

b64size.i = StringByteLength(b64.s)

Debug "Original data size: " + Str(size.i) + " bytes"
Debug b64.s
Debug "Bytes to transfer to WebViewGadget: " + Str(b64size.i) + " bytes"
Debug "Overhead: " + StrF(b64size.i/size.i) + " times"

So the 250MB data will need to handle and transfer 650MB of data to and from the WebViewGadget if I use base64...

Or am I completely wrong?

[Kukulkan]

As an alternative approach, I consider running a small webserver in the app using PB CreateNetworkServer() and binding it to 127.0.0.1. Then, the webview might connect to this and request or push binary data much more efficient. But the opened port on localhost would be open for other local apps, too. There is the real risk of abuse. I also fear that antivirus and firewall tools will then be a problem for my application (which will result in a lot of support calls).

What do you think? Other alternatives?

[Fred]

I don't think there is an easy solution for this as string are a requirement when using the callback. The string + base64 overhead is only temporary though, is that really a concern ? Even basic apps like MS Teams takes 1 GB of ram idle spawn tons of WebView2 in the background. If you think it's a problem, you can probably stream the output and decode it step by step by calling several time the callback.

[Kukulkan]

Hi Fred, thanks for your reply. I'm mainly concerned by speed issues because of the additional base64 encoding/decoding and additional json encoding/decoding. The today native app is really fast. The needed transfer overhead for the WebViewGadget will cost a lot of CPU and memory for encoding/decoding and string operations.

On mobile devices I've already encountered size limits like around 50MB on modern iPhone and WKWebView usage. They have HEAP size restrictions there, limiting my app to attachments with less than 10 MB. Similar on Android. Also, the maximum length of string parameters seems limited there. I assume and fear similar limits on WebViewGadget (using webview which utilizes GTK, WebKitGTK, Cocoa, WebKit, Windows API and WebView2) and fear the discovery later at the customers...

[Fred]

The CPU overhead should be minimal as base64 encoding is very very cheap, so to me it mostly seems a memory concern. Did you test in real world situation to see what's the real impact is ? BTW, what do you transfer to the webUI ? did you compress it before running base64 ?

[Kukulkan]

Hi Fred. I already implemented it for mobiles using Kotlin (Android) and Swift (iOS) both using native offered WebView. On both I have massive memory size issues, crashing the App if someone tries to attach, for example, a 20MB video. I managed to enhance a bit by doing b64 encoding/decoding in chunks, but the memory consumtion of the WebViews seems limited in general and on HEAP side. I was finally forced to implement size limits for the users to prevent crashes.

I did not yet try with PB on all platforms. I hoped that some general information about existing limits is available before spending to much time on this...

No, I do not use compression. People usually add office documents (like docx or xlsx) and images (mainly png or jpeg) in 99%. They are usually compressed already by specification and I do not try to enhance this any more.

[Fred]

You can't compare mobile app and desktop app, there is no hard limit for desktop as it's on the mobile space. My guess is you won't have much trouble, 650 MB of mem isn't a lot nowaday. I'm not aware of WebView memory limit (and it shouldn't have IMHO)

[Kukulkan]

Thanks Fred. Okay, at least, there is no known limit. Which is much better that the answer that there are limits in a critical area for me