Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dart: Return dart:typed_data equivalent where possible #8289

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

NotTsunami
Copy link

@NotTsunami NotTsunami commented Apr 22, 2024

Stems from discussion in #8183. This should allow users to be able to access a Uint8List directly without copying over from a list, thus actually offering zero-copy access (for this class, at least) in both the lazy path and the non-lazy path. This is pretty important for signal processing and image processing where we want to avoid any unnecessary list copies.

* Uint8List is a subtype of List<int>, so the API is functionally unchanged
* Remove now unused _FbUint8List class
* Int8ListReader was erroneously using the _FbUint8List class, use the correct _FbInt8List class
* Remove unnecessary cast from _writeUTFString to silence lint warning
@github-actions github-actions bot added the dart label Apr 22, 2024
@jamesderlin
Copy link

jamesderlin commented Apr 22, 2024

ByteBuffer has an asInt8List method along with asUint8List, so for symmetry perhaps a Int8List _asInt8List(int offset, int length) method could be added Buffeto rContext, and _FbInt8List could be removed?

@NotTsunami
Copy link
Author

NotTsunami commented Apr 22, 2024

ByteBuffer has an asInt8List method along with asUint8List, so for symmetry perhaps a Int8List _asInt8List(int offset, int length) method could be added Buffeto rContext, and _FbInt8List could be removed?

I'm not opposed to that, but I'd like to see some insight from one of the Dart maintainers to see if this aligns with their view for the Dart side. Ideally, we could expand the same to Uint16ListReader to use their more space-efficient dart:typed_data alternatives (assuming those two follow the same pattern of being subtypes of List<int>), but then the question arises should those classes also offer lazy/greedy paths?

@NotTsunami NotTsunami marked this pull request as ready for review April 23, 2024 14:14
@NotTsunami
Copy link
Author

Ready for review. I tested using @tompark's example code, with the latest version of flatbuffers on pub.dev as well as this fork, and this fork prints the expected bundle1.image1 is already a Uint8List, len=29149 while the latest version on pub.dev does not. The only difference in my test path is that I manually executed the steps from setup.sh instead of writing a script. All tests are passing as well.

cc @vaind I'd like some input on if this should extend to Int8List as well and if it's preferable to add another internal built-in _asInt8List like we have for _asUint8List or if it should just be inlined (the VM inlines it anyway).

@NotTsunami
Copy link
Author

I can provide a test repo if you'd like as well, although setting up Tom's example code also takes <10 minutes, assuming you have Flutter and Python already installed.

…respectively

* Remove now unused _FbUint16List and _FbInt8List builtin classes
* Add missing test for Int8List
* Small comment cleanup
* Silence lint warning about unused variable
@NotTsunami NotTsunami changed the title dart: Always return Uint8List for Uint8ListReader dart: Return dart:typed_data equivalent where possible Apr 23, 2024
@NotTsunami
Copy link
Author

NotTsunami commented Apr 23, 2024

I applied the same changes to Int8List and Uint16List, added a missing test for Int8List and applied type checking to each test.

NOTE: I changed the hex values in the expect() to match their correct decimal value to better differentiate between the Int8List/Uint8List tests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants