...Unfortunately, after a little bit of testing and a lot more thought and consideration, I've realized there really isn't a way to do this without doubling the allocation. Ouch.
Followup to these two commits:
02617a854dad3a632927
In the second commit, the buildBuffer call in HTTPRequest was
found to conflict with the way local requests are made, with the
bytes being set directly. So buildBuffer was moved to NativeHTTPRequest
instead. Upon promise completion, now, the value of bytes should always
be correct, and buildBuffer need not be called.
But buildBuffer is called again in NativeHTTPRequest.loadText. For local
requests, this will lead to the same problem that the second commit
fixed (presumably), and for network requests, this leads to the nulled
out buffer being accessed a second time, resulting in a crash.
So since the received value of bytes is already correct and buildBuffer
is harmful, the buildBuffer call is removed from loadText.
Both local and network requests are happy now!
The HashLink executable expects hlboot.dat and libraries to be in the current working directory (it's not enough for them to be in the same directory as the executable). Make the .app file launch a shell script that 1) changes the current working directory 2) launches the HashLink executable
This change places the focus on the one known use case, while clearing
up potential confusion caused by similar-sounding classes that function
totally differently.
vorbisFile.timeTell() returns the current decoding offset in seconds,
and it's updated each time vorisFile.read() is called. Since data is
buffered by calling vorbisFile.read() multiple times, the associated
time values also need to be preserved in order to get the correct time
offset.
Without this change, getCurrentTime() will return some time in the
future relative to the amount of buffered data.
I can't think of any practical reasons for an Android extension to compile an ndll. All of Android's system functions require Java, not C++, and you can get the speed of C++ just by writing Haxe code.
I surveyed several Android extensions on lib.haxe.org, and not one of them used ndlls when targeting Android.
Turns out, `HTTPRequest`'s call is only needed for internet requests.
Files on the local machine will be loaded directly into `bytes`, leaving
`buffer` empty. Calling `buildBuffer()` will then delete the data.
Pros: It's a standard Haxe feature that other Haxelibs may rely on. Plus
it offers built-in thread safety, unlike `onUpdate`.
Cons: It incurs two `mutex.acquire()` calls per frame.
