Yesterday we open-sourced and It's an early preview, be gentle with it :) Anyone wants to ask me about it in person I'll be at #fluttervikings.

@SuprDeclarative Wish somebody added material to that :)

@OrestesGaolin I'm not sure what you mean by frame skipping gestures? I don't think this will affect that in any way. Do you have a specific Flutter issue in mind?

@mraleph @SuprDeclarative @jezell @dart_lang I think the initial buffering is in network stack, because it completely disappears when using network link conditioner. Probably not something we can do anything about.

@SuprDeclarative @mraleph @jezell @dart_lang In the end multipart request is a stream piped to a socket which reads from it. Is there a straightforward way to run your example?

@SuprDeclarative @jezell @mraleph @dart_lang I think pipe() calls _HttpOutgoing.addStream (dart sdk, http_impl.dart), which then wraps it and passes the controller to _SocketStreamConsumer (socket_patch.dart), which should do the right thing and pause the stream as needed. But maybe I got lost somewhere on the way.

@SuprDeclarative @jezell @mraleph @dart_lang It shouldn't be. You might want to debug it to see what is causing the eager reading. Default dart http client shouldn't, neither should cupertino_http. Cronet buffers the request eagerly, and it also happened for me with proxyman enabled.

@SuprDeclarative @jezell @mraleph @dart_lang No. Your ReadProgressMonitor will eagerly read entire stream and write it to sink, which will likely buffer the entire contents. Again, there's no back pressure. Dart streams are bit tricky to work with. You can use to track the number of bytes sent.

Android developer friends, maybe you can help me here. I'm writing a custom ContentProvider that generates PDF files on fly. Works with any PDF viewer I throw at it, except the Google Drive app. It fails with an error, before I even write anything to the pipe. Any ideas?

@jezell @SuprDeclarative @mraleph @dart_lang No blobs, just file objects received during drop.

@SuprDeclarative @jezell @mraleph @dart_lang I was actually using package:http instead of raw dart:io, my bad. Extend http.BaseRequest, return multipart stream from finalize. The read progress of the stream should match upload progress. You can't be "adding" anything anywhere, there's no back pressure, it needs to be pull.

@SuprDeclarative @jezell @mraleph @dart_lang Cronet is broken (reads the entire stream upfront), and so is dio. It tracks the read progress of the stream, but then it copies it to another when constructing multipart request essentially buffering everything in memory. So the only way is to assemble the request yourself.

@daniel_kiing3 Not sure what you used for drag & drop, but super_drag_and_drop will do the trick (including multi item drag & drop on iOS).

Nevermind, I can log it, I thought the private field was blacklisted. Turns out it's just that android developers, in their infinite wisdom, renamed the field from "fd" to "descriptor".

@vatsal_manot I honestly don't know enough about SwiftUI to argue with this, so I'll take your word for it :) Tbf, my biggest problem with SwiftUI probably is not the performance, but how opaque it is.

Building #flutter engine on arm64 windows VM on a M1 MAX is not for the inpatient. Nonetheless, it's pretty impressive that it actually works.