TheRealTimeWeb.com: Is there a valid reason why we cannot send Bitmapdata objects via FMS2?

Is there a valid reason why we cannot send Bitmapdata objects via FMS2?

Posted by Stefan Richter in General | 9 Comments

It's that time of year again. Let's moan about the lack of screensharing...

I was reading an older post by Jesse Warden today in which he theorizes that Adobe may be withholding the ability for sending Bitmapdata objects via a Netconnection simply in order to keep Breeze's toolkit ahead of FMS2 (ok, Jesse didn't put it that way but I think that's what he meant), basically discouraging developers from being able to build their own Breeze's. The more I think about it the more angry this makes me... I should have ranted about this much earlier.

We all know that pretty much every Flashcom developer has to date built some kind of a mini-Breeze app, and some implementations are very neat indeed. People (myself included) have even found ways to work around the lack of screensharing using third party screen capture drivers such as the VH Screen Capture Driver for example. Make no mistake though, while it may be a workable solution it is nowhere near as integrated as Breeze makes it. Quality and bandwidth consumption are other issues you may run into.

If it was possible to send Bitmapdata objects (a Flash 8 feature) via a Netconnection (and FMS2) then that would make it fairly easy to build some basic screensharing applications. Granted, I don't know what framerate you could achieve but that's not the point. The point is that for some mysterious reason it is not possible to send Bitmapdata objects via FMS2 as I have found out a while ago. But why not?

I have heard many theories as to why it is that screensharing capabilities have been omitted from FMS2. It seems quite obvious that Adobe wants to keep Breeze ahead of the pack. However some of the reasons came directly from Adobe and while I cannot tell you what those reasons are I can say that they do not support the lack of Bitmapdata over a Netconnection. It just seems like yet another stab in the back to me. The conflict of interest here is just unreal - and before the merger someone put this very well: it is as if Adobe would be running design studios while also selling Photoshop (but they'd probably drop the undo tool).

Call me a conspiracy theorist but this stinks.

Tweet Follow @stefanrichter
Posted on January 25, 2006 at 2:17 PM. 7019 views. 9 comments. Print

TweetBacks

Comments

[Add Comment] [Subscribe to Comments]

#1 by Brian Lesser on 1/25/06 - 2:14 PM

Extending the player to integrate screen sharing was relatively easy for Macromedia (now Adobe) to do for their own applications. Extending the player to support anyone's application is more work and would cost them more. They don't see any financial incentive to do it. They really aren't focused on making Flash the killer RIA platform from end-to-end. They want to $leverage$ the ubiquity of the player.

My favorite quote from Bob Burgess:

"And, so, the fact that we own the client as well as the server gives
[us] a long-term competitive advantage."

See: http://knowledge.wharton.upenn.edu/article/1059.cf...

They want their proprietary protocols in the player to give them ownership of the server side.

Cheers,
-Brian
#2 by stoem on 1/25/06 - 2:23 PM

just how proprietary are these protocols these days? AMF? RTMP?
#3 by Dominick on 1/25/06 - 2:44 PM

now that they mm/adobe consulting, that competitive advantage has really shaped itself in their favor. Not cool!
#4 by JesterXL on 1/25/06 - 4:14 PM

...actually, I think it's both the fact they need it, but also filesize. The amount of RAM bitmapData takes up is insane! I haven't really done much bitmap playing since 2001 with Director, so I had forgotten (or maybe I never knew?) how much RAM bitmaps take up.

For example, 2880x2880 is the maximum image size in Flash. That takes up 44megs, even if it's blank.

Ok, divide that by 3... that's still like 22megs. How in the hell are you going to shove that over the wire without some sort of compression (like PNG/lzw/etc.)? I almost think it was mostly to prevent us from shooting ourselves in the foot.

Granted, some of the image compression algos that were written when Flash 8 was released will run reasonably well in Flash 8.5 because of it's awesome speed, but still... seems to me the use case is actually less prevalent because of bandwidth restraints. We really really really need to break the speed of light barrier.
#5 by stoem on 1/25/06 - 4:20 PM

yeah you got a point Jesse. But they didn't stop us from going mad with getPixel nor do they prevent me from adding cheesy music to my skip intro movies... :-)
Seriously, don't tell me which tools are good or bad for me. Don't stop selling knifes because I may stab you, all I want is to cut some salami man!
It still seems to be too much of a coincedence to me.
#6 by JesterXL on 1/25/06 - 4:50 PM

Naw, I still agree with you bro; if I were Macromedia, and I made as much bling as they do on Breeze, I wouldn't give you BitmapData either; I'd only allow it to be serialized/deserialiezd in the Breeze Player to ensure I had the best Whiteboard on the planet.
#7 by ethan on 1/25/06 - 6:45 PM

let's hope the guys working on red 5 can add this after the initial 1.0 release.
http://osflash.org/red5
-e
#8 by arnoud on 1/30/06 - 2:47 PM

yeah, let's hope so, but if red5 becomes better then mediaserver in these kind of respects, adobe probably is going to pull the plug by saying "you stole our proprietary RTMP protocol" so dump it or we sue your ass :)

And in some respect they are probably right too. (although it would suck of course :) )

all the best,
Arnoud
#9 by TMcCrystal on 2/2/06 - 2:30 AM

The "you can't send bitmaps" issue is one of the reasons that a lot of Director/SMUS server developers are still cheesed off at the forced migration to flashcomm. The old multiuser server could send bitmaps (or just about any other Director media type for that matter) from version one.

Of course, Macromedia wasn't competing against its developers in those days...

tmc