[acdha]

Hardware acceleration is a broad term used to describe different things and implementation quality still matters (i.e. does it do everything from format decoding to color conversion, scaling, compositing, etc. and are any individual steps combined?).

Every time I've done that comparison, Flash has used significantly more CPU for the same file. It's possible that they've finally managed to get close on the right combination of hardware, OS, and driver versions but given how regularly I still see people talking about huge improvements after uninstalling Flash, I'm skeptical that this is the most common experience.

Similarly, hardware acceleration was not a given in the past and since there's still plenty of buggy hardware and drivers out there, both Flash and all major browsers have software playback paths and there's even more room for variation there. It's not as bad as when people were comparing Flash's scalar code to Apple's well-optimized SIMD but if you disable hardware acceleration you can still see major deltas because Adobe was never willing to invest the same amount of effort in optimization. This hit Flash more because there were design constraints which caused it to silently disable HW acceleration and developers using fast desktops often didn't notice that happening.

Flash was never better than the native AV frameworks on Windows or OS X. What it offered was convenience during the period when you couldn't rely on everyone having support for a modern video codec and, of course, being able to do things other than simply play back a video file.

[fenomas]

To clarify I was mainly talking about the days when HTML video was newish and flash was still a big priority to Adobe, and there was uncertainty which would win. I agree with what you're saying over the long run and certainly today.

But I'd have to quibble with saying flash was never better than native playback - presumably so for raw performance, but that wasn't the goal. Flash video was never great for being technically superior, it was great for cutting the Gordian knot that was the codec problem (and indeed one presumes technical tradeoffs had to be made to that end).

[acdha]

The codec problem was real but portability didn't make the performance (or reliability & security) problems inevitable. That was due to Adobe's management seeing the period of browser stagnation & the lack of widely available high-quality codecs as the natural order of things rather than an unlikely opportunity which they'd lucked into.

It's interesting to speculate about what might have happened had they chosen to cultivate a culture of software quality rather than putting everything on customer-milking mode. If Flash had performed well and been well-supported with a non-joke update strategy, Steve Jobs wouldn't have had so many enthusiastic supporters in the war on Flash and the second round of browser wars might never have heated up.

I count myself in that camp in part because I've always preferred the web's openness but also because I used Flash for a few projects and saw how horrible the experience was – technical debt at record levels, clumsy development tools and lousy documentation, and the $800 price didn't even buy reading comprehension on support requests. Fortunately, WebKit was getting serious traction by then so it became increasingly easy to avoid it. If I had any doubts about that call, it was confirmed when the next Flash release came out a year or so later and all of my bug reports were closed with a generic “please pay $900 to see if this was fixed” message after I'd gone to the trouble of including reproducible test cases for each one.

[fenomas]

That seems like a pretty facile view to take. Fixing the video delivery problem isn't something Flash randomly lucked into - other technologies (Real, QT, etc) existed for no other reason but couldn't do it, because it was hard. Flash became the de facto global standard for delivering interactive content because it solved that problem, and a bunch of others, for a huge number of people, better than the alternatives, for years. If you didn't like the IDE that's fair enough but it's no grounds to claim the team behind it were money-gougers with no regard for software quality.

[acdha]

I base the claim that they were focused on short-term returns on the way bugs went unfixed and performance was neglected for most of that period until it was too late.

They beat Real/QT thanks to marketshare from the bundling deal they'd signed with Microsoft and I really think they thought that would last forever because nobody else would catch up. When the iPhone came out, the public statements made it clear that they didn't seriously expect the no-plugin policy to last or that it'd drive users away – and it certainly never looked like anyone took the ton of problems experienced by Android users seriously enough to take the product out of maintenance mode.

It took years of them being derided as the leading source of browser crashes and exploits before they even started to offer automatic updates in 2012! – and naturally they rolled their own so it didn't work reliably for years.

Similarly, performance was obviously not a priority until it started being heavily mentioned as a reason to prefer the HTML5 stack, at which point they were hopelessly behind and unwilling to invest enough to catch up.

I mentioned my poor support experience because that also fits with the general pattern. The bugs I reported were mostly in the runtime, although the IDE definitely had problems (stability, unreliable debugger, etc.), and all of this was well-known in the community along with the belief that the only way to get attention was if you worked somewhere large enough to buy millions of dollars worth of licenses.

All of that is consistent with my theory that the product management was focused on the short-term and loathe to spend money on anything which wasn't critical, which left them in the unenviable cycle of reacting late to threats from a year or two ago rather than leading anything. If they'd invested in quality during the early 2000s the last decade might have gone very differently.