Domain: kaourantin.net
Stories and comments across the archive that link to kaourantin.net.
Comments · 35
-
Linux Flash playback is NOT hwaccelerated on Intel
I have the native 64 bit Flash plugin I can tell you that it is not THAT smooth and accelerated on many Intel GPUs. You may wish to qualify your statement with some links (the PenguinSWF blog talks about the issues). On the same machine that struggles with certain Youtube Flash videos on Linux, the performance is fine under Windows. I believe you will need your GPU to have at certain GL features for support for significant Flash acceleration under Linux and if your GL driver returns SGI string it will typically default to not turning acceleration on to avoid problems for those with weak GL implementations.
This is well known and is not a conspiracy. For a while OSX was in a similar position.
-
Re:What I care about
Are the h.264 people offering indemnity?
No. But they have tons and tons of patents on h.264, and h.264 and WebM are very, very similar. So we can quite safely assume that WebM is infringing on a substantial number of patents. At least we can assume that there are tons of patents where a claim that WebM infringes is not unreasonable. And you don't even need a _reasonable_ claim to sue for patent infringement.
Or Vice versa On2 has been doing codecs for a long time
http://en.wikipedia.org/wiki/VP8
http://en.wikipedia.org/wiki/VP7
http://en.wikipedia.org/wiki/VP6
http://en.wikipedia.org/wiki/VP5
http://en.wikipedia.org/wiki/VP3
In fact fun article of why flash chose VP6 over H.264 in 2005 my favourite bit is "Risks for Macromedia. We had to know exactly what we were getting into. A codec with an open ended license agreement which has to be renegociated every few years simply bear incalculable risks for a company the size of Macromedia." http://www.kaourantin.net/2005/08/quest-for-new-video-codec-in-flash-8.html
-
Re:Apple provided APIs
It's really pretty simple: Adobe doesn't want to make the investment necessary to make the Flash player efficient, stable, secure, and bloat-free. On the other hand, they want to keep making money selling the Flash development tools.
Excuse me, but.... huh?
I'm going to assume you haven't actually researched this (i.e. "I went to the source and got the full story for myself" research and not just "I read a Slashdot comment once and got angry" research) and are just running at the mouth because you're angry, not because you're right.
Which you aren't.
Here, let me introduce you to a guy. His name is Tinic Uro, and he's one of the people who actually programs Flash. He's an engineer like us, not a marketing droid (or worse, an executive).
Here are three blog entries you should fully familiarise yourself with before making any further comment on what Adobe is doing in terms of improving Flash on OS X.
Flash 10.1 and Core Animation:
http://blog.kaourantin.net/?p=81
(TL;DR: yes, Flash 10.1 uses Core Animation to accelerate overall Flash graphics performance -- not video specifically -- but you need OS X Snow Leopard and a super-new version of Safari)Flash 10.1 and timing:
http://blog.kaourantin.net/?p=82
i>(TL;DR: They rebuilt the timer model in Flash 10.1 to use significantly less memory, however Safari on OS X is less flexible than other browsers when it comes to firing timer events, thus making video playback less smooth)H.264 hardware acceleration in OS X:
http://blog.kaourantin.net/?p=89
(TL;DR: Adobe has released a post-10.1 beta version of Flash that supports full and proper video H.264 acceleration on Mac OS X, with the caveat that you have to have 10.6.3 and certain current graphics chips)The real story is this:
Apple has been well behind Microsoft Windows when it comes to providing third parties with APIs to do hardware acceleration, and to do high-performing timer operations that are necessary to run browser plugins smoothly. I know the Slashdotterie will get all worked up over that assertion, but speaking as someone who's actually written browser plugin code, you'll just have to trust me on this. IE has always had the best timer support, which is one reason why video- or timeline-heavy plugins have always performed better than other platforms. As of OS X 10.6.3 and Safari 5, Apple has pretty much caught up.
- Despite the headline-grabbing statements from Steve Jobs and other executive-types, there are actual hard-working developers at Apple and Adobe who actually collaborated to define a good API for high-performance video access for browser plugins. If Apple wasn't so deliriously secretive, you'd hear a lot more about it. Trouble is.... the only people who are allowed to blog at Apple are people who'll make the company look good and forward-thinking -- like the Webkit team.
The problem with performance isn't 100% Adobe's fault. It can't be. Adobe's engineers aren't stupid -- if there had been an easy solution to good plugin video performance on the Mac all this time, they would've fixed it years ago. Why spend several years intentionally using a bad approach?
Lastly.... despite what the article summary says here on Slashdot, overall Flash performance is quite a bit better in 10.1, especially on OS X. Do your own benchmarking; you'll see for yourself. It's still not as good as it should be, but it's a massive step forward. They know HTML5 is coming... they know they have to make Flash as good as or better than HTML5 or they'll be toast by 2020. They know all this.
-
Re:Apple provided APIs
It's really pretty simple: Adobe doesn't want to make the investment necessary to make the Flash player efficient, stable, secure, and bloat-free. On the other hand, they want to keep making money selling the Flash development tools.
Excuse me, but.... huh?
I'm going to assume you haven't actually researched this (i.e. "I went to the source and got the full story for myself" research and not just "I read a Slashdot comment once and got angry" research) and are just running at the mouth because you're angry, not because you're right.
Which you aren't.
Here, let me introduce you to a guy. His name is Tinic Uro, and he's one of the people who actually programs Flash. He's an engineer like us, not a marketing droid (or worse, an executive).
Here are three blog entries you should fully familiarise yourself with before making any further comment on what Adobe is doing in terms of improving Flash on OS X.
Flash 10.1 and Core Animation:
http://blog.kaourantin.net/?p=81
(TL;DR: yes, Flash 10.1 uses Core Animation to accelerate overall Flash graphics performance -- not video specifically -- but you need OS X Snow Leopard and a super-new version of Safari)Flash 10.1 and timing:
http://blog.kaourantin.net/?p=82
i>(TL;DR: They rebuilt the timer model in Flash 10.1 to use significantly less memory, however Safari on OS X is less flexible than other browsers when it comes to firing timer events, thus making video playback less smooth)H.264 hardware acceleration in OS X:
http://blog.kaourantin.net/?p=89
(TL;DR: Adobe has released a post-10.1 beta version of Flash that supports full and proper video H.264 acceleration on Mac OS X, with the caveat that you have to have 10.6.3 and certain current graphics chips)The real story is this:
Apple has been well behind Microsoft Windows when it comes to providing third parties with APIs to do hardware acceleration, and to do high-performing timer operations that are necessary to run browser plugins smoothly. I know the Slashdotterie will get all worked up over that assertion, but speaking as someone who's actually written browser plugin code, you'll just have to trust me on this. IE has always had the best timer support, which is one reason why video- or timeline-heavy plugins have always performed better than other platforms. As of OS X 10.6.3 and Safari 5, Apple has pretty much caught up.
- Despite the headline-grabbing statements from Steve Jobs and other executive-types, there are actual hard-working developers at Apple and Adobe who actually collaborated to define a good API for high-performance video access for browser plugins. If Apple wasn't so deliriously secretive, you'd hear a lot more about it. Trouble is.... the only people who are allowed to blog at Apple are people who'll make the company look good and forward-thinking -- like the Webkit team.
The problem with performance isn't 100% Adobe's fault. It can't be. Adobe's engineers aren't stupid -- if there had been an easy solution to good plugin video performance on the Mac all this time, they would've fixed it years ago. Why spend several years intentionally using a bad approach?
Lastly.... despite what the article summary says here on Slashdot, overall Flash performance is quite a bit better in 10.1, especially on OS X. Do your own benchmarking; you'll see for yourself. It's still not as good as it should be, but it's a massive step forward. They know HTML5 is coming... they know they have to make Flash as good as or better than HTML5 or they'll be toast by 2020. They know all this.
-
Re:Apple provided APIs
It's really pretty simple: Adobe doesn't want to make the investment necessary to make the Flash player efficient, stable, secure, and bloat-free. On the other hand, they want to keep making money selling the Flash development tools.
Excuse me, but.... huh?
I'm going to assume you haven't actually researched this (i.e. "I went to the source and got the full story for myself" research and not just "I read a Slashdot comment once and got angry" research) and are just running at the mouth because you're angry, not because you're right.
Which you aren't.
Here, let me introduce you to a guy. His name is Tinic Uro, and he's one of the people who actually programs Flash. He's an engineer like us, not a marketing droid (or worse, an executive).
Here are three blog entries you should fully familiarise yourself with before making any further comment on what Adobe is doing in terms of improving Flash on OS X.
Flash 10.1 and Core Animation:
http://blog.kaourantin.net/?p=81
(TL;DR: yes, Flash 10.1 uses Core Animation to accelerate overall Flash graphics performance -- not video specifically -- but you need OS X Snow Leopard and a super-new version of Safari)Flash 10.1 and timing:
http://blog.kaourantin.net/?p=82
i>(TL;DR: They rebuilt the timer model in Flash 10.1 to use significantly less memory, however Safari on OS X is less flexible than other browsers when it comes to firing timer events, thus making video playback less smooth)H.264 hardware acceleration in OS X:
http://blog.kaourantin.net/?p=89
(TL;DR: Adobe has released a post-10.1 beta version of Flash that supports full and proper video H.264 acceleration on Mac OS X, with the caveat that you have to have 10.6.3 and certain current graphics chips)The real story is this:
Apple has been well behind Microsoft Windows when it comes to providing third parties with APIs to do hardware acceleration, and to do high-performing timer operations that are necessary to run browser plugins smoothly. I know the Slashdotterie will get all worked up over that assertion, but speaking as someone who's actually written browser plugin code, you'll just have to trust me on this. IE has always had the best timer support, which is one reason why video- or timeline-heavy plugins have always performed better than other platforms. As of OS X 10.6.3 and Safari 5, Apple has pretty much caught up.
- Despite the headline-grabbing statements from Steve Jobs and other executive-types, there are actual hard-working developers at Apple and Adobe who actually collaborated to define a good API for high-performance video access for browser plugins. If Apple wasn't so deliriously secretive, you'd hear a lot more about it. Trouble is.... the only people who are allowed to blog at Apple are people who'll make the company look good and forward-thinking -- like the Webkit team.
The problem with performance isn't 100% Adobe's fault. It can't be. Adobe's engineers aren't stupid -- if there had been an easy solution to good plugin video performance on the Mac all this time, they would've fixed it years ago. Why spend several years intentionally using a bad approach?
Lastly.... despite what the article summary says here on Slashdot, overall Flash performance is quite a bit better in 10.1, especially on OS X. Do your own benchmarking; you'll see for yourself. It's still not as good as it should be, but it's a massive step forward. They know HTML5 is coming... they know they have to make Flash as good as or better than HTML5 or they'll be toast by 2020. They know all this.
-
Re:Can it be used for plugins?
The versions of the swf that are open do not include all features. It's a "when we get to it" approach from Adobe. The end result is that they open up version 8 and then release version 9. We're now on version 10 and not all features are available. The end result is that the open plugins are never up to date and Adobe is the only place to go to, yet they get to keep the appearance of being open to dupe people like you.
The version 10 SWF spec is available right here. So let me get this straight: Adobe openly publishes all updates to the SWF spec, but none of the open source Flash-clone projects have actually picked up the updates yet... and that's Adobe's fault?
I'd also argue that you're living in Adobe's ideal world which is Windows. NONE of the flash plugins outside of windows support hardware acceleration, they're stuck on your core process support.
Until very recently, Mac OS didn't offer any public APIs appropriate for hardware-accelerating Flash's video decoding. The new APIs are the result of collaboration between Adobe and Apple engineers, and a new Flash beta is already available that uses them.
-
Re:I'm still not getting this 'buggy' claim
Keep in mind that Apple only recently provided API support for hardware acceleration, and even then -- Apple only provides an API to accelerate video under certain conditions, for only their most recent hardware. For whatever other ways you want to blame Adobe for the "slowness", Apple needs to own up to a fair share of this one.
-
Re:Whoosh!
Likewise, what about the HW vs SW argument? It's easy for code developers, some of whom I'm guessing have invested a fair about of time and training in becoming adept at flash, to just wave their arms and say "battery life is somebody else's problem". Well, yes, the hardware manufacturer's, for one. Here is a hardware manufacturer's response. Etc.
Okay, let's talk about the HW vs SW argument. Adobe needed API support from Apple before they could add hardware video decoding to their Flash Player. This API was only added in OSX 10.6.3, and even then, won't even run on my Macbook Pro, because it's older than a year and a half old, and Apple is not (yet?) providing API support for older hardware. You can rest assured, that now that Apple has finally provided an API for developers to use, Adobe has jumped on it, but due to Apple's half-way job of it, much of Apple hardware is not supported.
Oh right, I forgot -- I'm supposed to believe Adobe has been the sole lazy company here. Adobe recognizes they have more resources available that they're not yet utilizing -- but these were only recently made available by Apple.
Somehow Steve forgot to mention this in his tirade, didn't he? Convenient.
-
Re:None of this would've happened...
So how exactly would you handle drawing within a browser plugin? I've pasted this elsewhere in this thread, but for the sake of showing that it isn't as simple as you and others make it seem: http://www.kaourantin.net/2010/02/core-animation.html
-
Re:None of this would've happened...
-
Re:Let's wait and see
I was pretty sure that you could do this with the Quartz Compositing APIs or with Core Animation, but I did some googling to see if I was wrong. I ended up stumbling across this blog which is apparently written by an Adobe engineer working on the Flash Player. Going by what he says, they've just recently started using the Core Animation API which gives them access to what they need with respect to features, and also access to OpenGL. They've already seen some performance improvement and with the ability to push stuff through OpenGL, more performance should be on the way. It's just a matter of Adobe programmers learning their way through the OS X programming model.
-
Re:Eat my balls!
Steve Jobs has been reported as saying that Flash sucks, is too slow and unstable, and takes up battery life. This is true.
You might want to ask all those other smartphone manufacturers why they're happily planning to support the upcoming release of Flash, then. Or could it be possible that Steve has other motives for keeping Flash out of the iPhone ecosystem?
on OSX, Flash is a disaster
Adobe has said in the past that API limitations in Mac-based browsers prevent them from bringing performance up to par with Windows. Someone just below in this thread posted a link to one of the Flash engineers explaining how Adobe and Apple are actually working together to fix this.
-
Re:Eat my balls!
Apple bans Flash because they are tired of dealing with Adobe. Only now is performance suddenly important to them, over half a decade after buying Macromedia.
And the response from the minority party, presented by Tinic Uro of Adobe:
-
Re:Adobe
VLC can do hardware acceleration. The Flash Player can not. (with some exceptions)
-
Re:Why linux first
For what value of "great"?
FreeBSD users and devs, for example, have asked for just as long.
As one of their devs wrote, it still needs some work:
The 64-bit version of the plugin compiles and runs on FreeBSD 7.0 which I demoed at Flashforward 2008. There are no plans for release yet as it is still rather unstable and will require substantial work to get it ready for public consumption.
But hey, they're actually working on a FreeBSD port.
-
Summary is wrong: Debugger *is* planned
From the blog of Tinic Uro, the engineer who did the bulk of the work:
http://www.kaourantin.net/2008/11/64-bits.html
A debugger version of the 64-bit version is not available yet. When we release it ActionScript 2 debugging will not work due the obsolete protocol which depends on 32bit pointers. ActionScript 3 debugging will be supported.
-
Re: news is already available
Most of the 64-bit work is still in the opensource Tamarin Project. You can still contribute, if you've got the chops.
http://blogs.adobe.com/penguin.swf/2006/10/whats_so_difficult_64bit_editi.html
http://www.kaourantin.net/2006/11/spidermonkeys-relative-tamarin-joins.htmlThe "we'll maintain it for you" line has not particularly been borne out by experience....
;-)jd/adobe
-
Re:Not sure what to think...No intention of porting Flash to x86-64 platforms, on Linux -or- Windows (at least AFAIK) Tinic Uro, an engineer on the Flash Player team at Adobe, has stated on his blog (on several occasions) that the port to 64-bit is in progress. He's explained that Flash Player has a lot of legacy code that needed to be optimized to run well on slower computers. That means some of it is specific to 32-bit architectures so that they could get every last bit of speed and cut memory use down on those poor ancient machines. Changing stable code shouldn't happen lightly. Unlike many open source projects, a nearly-ubiquitous runtime like Flash Player needs to focus more strongly on stability and compatibility between versions. Adobe is committed to backwards compatibility, and there's nine versions of the SWF format they have to account for and test against.
-
Platforms supported by Flash Player and Flash Lite
I keep hearing contradictory claims about the platforms supported or not supported by Flash Player or Flash Lite... Adobe's website is uninformative. Even their wikipedia articles are imprecise. AFAIK:
- Flash Player, which is the regular browser plugin, is currently (version 9) only available for the i386 architecture ( this flash developer claims the JIT compiler in the Flash VM is delaying the port to x86-64). Older versions (7 or earlier ?) used to be available for the PPC arch for Mac OS, but PPC support was dropped approximately when Adobe acquired Macromedia.
- Flash Lite is a lightweight version of Flash Player that runs as a standalone app (as opposed to a browser plugin) and is available on various smartphone platforms: ARM, MIPS (I think ?). It is very unclear what features are supported by Flash Lite exactly (video ? action script 3 ?).
Could someone knowledgeable clarify ?
-
Flash now supports AAC & H.264
Actually the next release of the flash player (currently in public beta) supports both AAC audio and H.264 video. These are both fairly open formats from what I understand.
This was announced several months ago:
http://www.kaourantin.net/2007/08/what-just-happened-to-video-on-web_20.html -
H.264 and AAC are still patentedComponents such as flash video are patented. That's changing. The latest beta of the Flashplayer supports h.264 video with AAC audio in an mp4 container. H.264 and AAC are still patented in the United States. The United States is relevant because Slashdot is on United States soil. For video content, publishers can choose between an open standard with free tools, or a proprietary expensive one, so what do you think will they do? For services that face the general public, they will likely use the one that is proprietary expensive due to United States patents (H.264) because the open standard with free tools (Ogg Theora) isn't popular enough on Windows.
-
Re:Gnash
The problem with flash and great projects like gnash is that it will never be a full freely distributable implementation as long as we have draconian patent laws. Components such as flash video are patented. Likewise the silverlight won't be complete in a free distribution.
That's changing. The latest beta of the Flashplayer supports h.264 video with AAC audio in an mp4 container. Mozilla Tamarin is the VM introduced in Flashplayer 9 and targeted by everything ActionScript 3 (like Flash CS3 can and Flex 2 always does, as well as the to-be-Free Flex 3 SDK). It's much faster than the one in previous versions, so developers will use that one increasingly. For video content, publishers can choose between an open standard with free tools, or a proprietary expensive one, so what do you think will they do?
That's two major building blocks right there. The rest of the format is basically just tags that define, transform and place sprites. Gnash already does a good job at that. Some pieces in the Adobe Flashplayer's renderer are patented, but there are excellent libraries for that. Of course, the API would have to be implemented (the flash.* packages, mx.* builds on that and will be part of the Flex 3 SDK).
The SWF specification isn't the problem, there are some Free tools out there that already have very good support of SWF and related protocols. With the Flex 3 SDK, there will even be one from Adobe you can legally look at (IANAL).You have to understand that Gnash tries to support existing content first. That is a big task, and I wish them well. But if you leave out legacy support and focus on what Adobe's current tools put out, it gets much easier. Grossly simplified, there's the VM, there are readers, renderers and codecs, add glue.
-
Re:Amazing
Comments from the Adobe engineers on 64-bit player work:
http://blogs.adobe.com/penguin.swf/2006/10/whats_s o_difficult_64bit_editi.html
http://www.kaourantin.net/2006/10/flash-player-9-f or-linux-beta-1.html -
Read these before you spread FUD
Here is the official Adobe Announcement:
http://www.adobe.com/aboutadobe/pressroom/pressrel eases/200611/110706Mozilla.html
And here is a great blog post from Tinic, one of the Flash Player engineers:
http://www.kaourantin.net/2006/11/spidermonkeys-re lative-tamarin-joins.html
And the Tamarin FAQ:
http://www.mozilla.org/projects/tamarin/faq.html
Please read these before you post FUD. Oh wait... This is /. FUD away. ;) -
Re:Jumping the Gun
They are not offering flash but they are open sourcing the Verifier, JIT, core frameworks and the garbage collection engine http://www.kaourantin.net/2006/11/spidermonkeys-r
e lative-tamarin-joins.html. The the newest Adobe ECMAScript VM is small and very fast and further along than Spider Monkey. This is very good for everyone involved, I believe, and a nice step by Adobe. Mozilla/Firefox users get a better ECMAScript engine and Adobe can concentrate more on the flash side of the flash engine. Read more at the FAQ on Tamarin http://www.mozilla.org/projects/tamarin/faq.html -
Re:Jumping the Gun
You're incorrect. See this blog entry from an Flash Player engineer: http://www.kaourantin.net/2006/11/spidermonkeys-r
e lative-tamarin-joins.html
It is not an attempt to re-implement the ActionScript Virtual Machine (runtime). It *is* the ActionScript Virtual Machine. Adobe and Mozilla are working together to build a common runtime, that already exists in Flash Player 9 and is already ECMAScript 4 compliant. Adobe just saved Mozilla a lot of time and hassle by giving them a high performance virtual machine that already implements the ECMAScript 4 spec.
Any changes Mozilla makes will find its way into the Flash Player. Any changes Adobe makes will find its way into Firefox. -
Should be much faster
Previous revisions of Flash Player for Linux preformed very poorly compared to the win32 versions (even the win32 verison in crossover office did a better job).
Yeah, Tinic ranted about that on his blog a while ago, saying he used wine for Flash on Linux (before v9, obviously) -- and he's a FlashPlayer engineer. His entry about this beta release addresses performance. He says he's not happy with the current state of font rendering speed yet, but that it beats the Windows version by 20% with other stuff. They're still working on it.
Over all, you should see better performance of existing content, thanks to the new rendering engine introduced in v8. This is especially true for SWFs (competently) written for v8 and using cacheAsBitmap -- not rerendering vectors every frame seems to improve performance. Who would have thought...
The second performance increase will probably take a while to become common: FP9 comes with a new, JIT compiled VM. The old one is still included for backwards compatibility, but once FP9 has a good install base and is supported by developers making scripting-heavy stuff, you should definitely notice the performance increase -- it's much, much faster.
If somebody feels like playing with it, there's the free (beer) Flex SDK on the Adobe site somewhere. However, I'd like to recommend haXe, a Free (capital F) compiler for a very fine language, with a great type system, that I really enjoy coding in. It supports Flash 6 to 9, the Free NekoVM, and can generate JavaScript (Yes! Typed!). Windows users can use the FlashDevelop plugin, for the rest of us there's Eclipse with EHX.
-
Re:AMD64 version?
From Tinic Uro's blog:
http://www.kaourantin.net/2006/10/flash-player-9-f or-linux-beta-1.html
What about 64bit? There is no Windows 64bit or OS X 64bit version either right now. As I said before it is not a question of 'recompiling' the source code, there is lots of generic non platform specific work which needs to be finished first. We will ship a 64bit version for Windows, OS X Leopard and GNU/Linux. It will happen. When? ... When it is ready. -
Re:Still vapourware until *something* gets release
* A definitive statement on whether they'll support 64-bit (i.e. "it'll be released at the same time as the 32-bit version" or "it'll be released X months after the 32-bit version" or "it'll never be released"). Sadly, Adobe are somewhat pig-ignorant w.r.t. the 64-bit platform and don't even have a 64-bit version for XP!
They've made their position on 64-bit support pretty clear.
Ignoring the 64-bit world seems shortsighted to me. Sure, most users are 32 bit at the moment, but are new 32 bit machines even sold any more? Old stock, maybe, before current models push it out of the supply chain. Even Semprons are 64 bit now.
-
Re:FVM2Um... did you notice the word "alpha"? As in, "not even beta yet"?
No, there's no OS X or Linux version yet. The alpha is Windows-only. OS X version is definitely planned, just not ready yet. I don't know what we've announced regarding Linux plans, so I can't comment on that.
Also true that there's no Linux version of Player 8 yet. But as one of the engineers on that team said, they're looking for experienced Linux engineers to help finish the port.
-
Re:Sorenson this time, not MPEG4
Wrong wrong wrong:
http://www.kaourantin.net/2005/08/quest-for-new-vi deo-codec-in-flash-8.html
Macromedia chose On2's VP6 codec (On2 is the company that donated VP3 to the OSS community - it's now known as Theora) because of patent and other considerations. -
Re:They're hiring
Porting the Flash Player to 'alternative' platforms
and it pretty much explains that there won't be a 64 bits version as long as they don't find a guru that will rewrite this beast. Not portable. -
Re:Anyone against SVG?
there is some very interesting comment regarding SVG, GNU/Linux etc. directly from a Flash Player developer:
http://www.kaourantin.net/2005/08/porting-flash-pl ayer-to-alternative.html
i guess, it's worth a separate discussion... -
Re:You can install on laptops
The problem isn't lack of interest, but lack of manpower.
See this blog entry by one of the Flash Player engineers discussing the problems in porting to Linux and AMD64... and note that and the end he comments:
"If you bothered to read to this point it means that Macromedia wants you really bad. Really, really bad. :-) We've been looking for Linux gurus for a while (well, it has been for more than a year now without anyone being even close to what we need, I guess they all go to Google...) and for best results they would have to be in house. Collaboration with the team here on a daily basis as a long term full time employee will be key to get the best results. So apply right now for this job. Not only will you be able to do exciting work on Linux, you'll even be paid for it!" -
Re:Ajax compared to Flash
- firstly, and this is very important, if a page is made entirely in flash then a search engine can't glean text from it when it comes to crawl it if all your content is compiled into a swf.
The search engine SDK (for people who make search engines) has been freely available since 2002. At the very least we know that Google does read the text in Flash files. (I honestly haven't kept track of other search engines - does anyone know?)
secondly, jpg images look crusty in flash.
In the past there were some bitmap display bugs in Flash. Tinic Uro, a Principle Engineer on the Flash Player, has a good blog post about the bugs they fixed in the latest release. I honestly don't personally know of any outstanding issues with bitmap display. Did you see any problems with the bitmaps in the Flash Earth page I linked to?
the quality of text rendered in a swf is fairly terrible when it's small
You have a point about older versions of Flash. You did have to take care with font selection and placement to get good quality at small font sizes. This is another problem that has greatly improved in the latest release. Flash 8 has a new font rendering system, "FlashType" (huzzah for the creative marketing team). The long and short is that it renders small type very well now. I've seen examples of the new type that I mistook for browser text before they were pointed out to be Flash.
text is unselectable
The selectability of type is a decision made at authoring time. It makes sense to have text selectable sometimes (eg body text), but not others (eg text on buttons).