That was my first idea, to pass VBA window handle instead of screen handle. Unfortunately, as it says in GetFrontBufferData() reference, this function only works at full screen level. Passing a window handle instead of desktop handle causes a D3DERR_INVALIDCALL.
I know that most live-streaming programs, which used DX9, usually captured specific areas simply by cropping Desktop capture, so it seems there was some kind of limitation in DX9 in that regard. Whether it's worth switching to DX10 or not I don't know(I'm really new to all this ), probably not, but it could potentially add to performance.
I played around a bit, and getting the internal buffer would kinda be dumb now that i think about it(and because everything i did wouldnt work as you said lol). But, because some apps use openGL, a directX handle wouldnt work across everything. So I decided to go a different route and this is what I came up with:
sorry about an alarm going off, i was using my phone. regardless....
EDIT: Code is much cleaner in the repo now
There have also been a lot of changes to wireless over the years, but not many improvements over the B/G spectrum. N and AC are where a lot of the focus is now in the 5Ghz spectrum. I think the improvement in speed is likely due to a lot of wireless routers and access points being capable of dual band which allows two streams of data transfer to take place at a time. Perhaps they added a second antenna to help which is one of the differences between the old and new 3DS.
I have a Meraki AP at home I could test with, it gives data input/output over time. Perhaps I can play with that over the weekend using youtube as a testing point on both units.
that info would definitely be sexy. but regardless of hte results, I think better compression would still be needed. OR! an Ethernet hardmod xD