OpenGL drivers on Windows are awful, DirectX is where all of the development effort goes on driver teams. At work we wrote our app using OpenGL for a 3D overlay because we ship on Windows, Mac, and Linux, but on Windows we took the time to write a DirectX backend instead of OpenGL and the stability and performance shot up noticably. OpenGL is a forgotten "checkbox feature" on Windows today, not much more.
Why not use system codecs? Because you're not solving the original problem. The problem was dependency on externally variable code that was frequently proprietary to render the web. Instead of requiring Flash to view websites in a default web browser, now we'll require K-Lite Codec Pack Max Extreme 2.0++?
Which codec would you use? Theora isn't implemented on most systems. h264 won't work on Windows by default (7 will, but that's just a small portion of the market). VC-1 won't work on Mac and Linux. MPEG-2 isn't even guaranteed to be found.
Congratulations...you've just opened a whole 'nother can of worms.
That's not true at all. Firefox, since 2.0, has had memory caching just like Opera does. Go to about:config and tweak how much is used (which is default-set based on your system capacity, just like Opera). It's called "browser.cache.memory.capacity".
I understand why they don't agree with the practice, but this is hardly front-page Slashdot news. The summary is, if anything, very misleading. This has NOTHING to do with Mozilla's plans for HTML5 or web openness, it's everything to do with some nameless blogger disagreeing with another nameless blogger's implementation of video fallback.
Some random Mozilla Hacks (note the word Hacks) blogger posts some code that web developers can use to implement HTML5 video (which does not use javascript, contrary to the implications in this article and summary?) and also provide a fallback path for non-HTML5 Video browsers (IE, Opera, etc). Their particular method of providing the fallback code uses javascript to determine browser capability, and uses Flash if HTML5 Video is not there.
Why is this upsetting to anyone? The implication from the summary is this is a less "open" way to do it, but last I checked Javascript/ECMAScript is a standard that all browsers implement already.
I cannot fathom why anyone would be so upset by some blogger providing JS-implemented video fallback implementations.
Firefox 3.5 implements the majority of those. IIRC Webkit and Safari are almost there too, and even MS is making a sprint to HTML 5 -- IE8 has started implementation there.
As for editors, yes -- they are under development.
Apple was far from the first company to implement multi-touch, it's just the first people think of. Multi-touch, and its patents, go back for quite a long time.
By definition, a superscalar processor does not need to be instruction re-ordering, speculative execution, or branch prediction. All a superscalar processor needs to do to be called superscalar is to dispatch more than one instruction per clock cycle to redundant functional units on the processor -- the 360's CPU is absolutely superscalar.
Incidentally, you are incorrect other aspects anyway: the Xenon cores DO have branch prediction, just in a significantly diminished capacity compared to what we're used to on the PC (small history tables, simpler logic, etc). The Cell's SPEs have none at all, and rely on "branch hints" instead where the programmer or compiler specifies which path may be likely at any given point. As a result, it also has speculative execution.
But you are correct in that the 360's CPUs -- like the Cell's PPU and SPEs -- is in-order and thus does not re-order instructions. It is up to the compilers to generate optimally ordered instructions, which isn't as big a deal as you may think on a closed-box system with optimized compilers. Back in '03-'04 I worked in IBM's compiler group on this very thing.
While it certainly sounds like you know what you're talking about, it's pretty clear to anyone with a game-dev background you do not.
Cell's SPEs are actually PRIMARILY used as aids to graphics processing (T&L) by most developers. Look into how games like Heavenly Sword use the SPEs as part of its "faux" HDR or games like Killzone 2 use SPEs to implement deferred rendering for awesome smoke effects. The SPEs are, in PRACTICAL TERMS to PS3 game developers, very essential to the 3D rendering side of the console.
While RSX is "powerful enough" to do its own T&L, it cannot compare to the standalone power of the 360's Xenos chip. There are many reasons for this (6 fixed vertex shaders on RSX vs the unified shaders on the 360 which permit far higher vertex workloads, to the RSX's limited bandwidth vs the 360's eDRAM bandwidth, to triangle setup rates). On the PS3, developers need to leverage Cell in intelligent ways to draw comparable graphics to the 360. If an intelligent and determined PS3 developer really leverages Cell, it can make unparalleled graphic in the console world. The problem is, it costs a fortune in time and money to do it and very few developers can. It's simply not worth it to even attempt it for most developers.
As a sidenote, Cell is not at all good for most game AI for many reasons (not the least of which is the lack of branch predictors in the SPEs).
Additionally, people keep making the mistake of assuming the PPU in the Cell is basically the same as each core in the 360's CPU. That's not at all true. There are some significant differences, including native Direct3D format support in the 360's CPU to the new VMX128 vector units (which have 128 registers per context per core [6 total], vs 32 on the PPU) as well as additional instructions specifically tailored towards 3D games (like single-cycle dot-product instructions). The combined triple VMX-128 units on the 360 are still faster than most quad-core Core i7 in vector processing, so I'm perplexed by the notion that it's somewhat slow or underpowered from what I've read from some people.
If you're truly interested in how PS3 games use Cell, check out the Beyond3D community where PS3 developers post in detail about how they do what they do. And Cell is a major factor in 3D rendering on the PS3. It has to be.
I wouldn't say IE8 took the context-menus from Mail.app, if anything Mail.app stole smart tags from Office...
Either way, if it's a handy feature, why not include it -- who cares who had it first.
As for the specific problem encountered in firefox, there is a perfectly acceptable and PUBLIC way of achieving the same thing,
This keeps being said, but it's not the same thing. The way FF got around it is on a Firefox-level XML-based fix. The way Webkit gets around it is a Webkit-level API-based fix.
Mozilla would like to do the same. Firefox is to Safari as Gecko is to Webkit. Gecko can and is embedded by other applications, and the optimal solution is to have this fixed in Gecko and not the container program.
Just how secret can it possibly be with publicly available release notes published years ago?
You are completely missing the point. There is no way to programmatically disable this with public knowledge, something Webkit did manage. All of the excuses on why no one else needs to do this except Webkit since it's embedded is nonsense -- Gecko is also embedded and can be used in other applications (and is used in other applications).
There's an API that is hidden in a binary blob to accomplish this. Apple chose not to make it public.
Yes, the/. story is sensationalist (when are they not?), but that doesn't mean there's not an issue here. WebKit is using internal Apple knowledge of undisclosed functionality in OS X and not telling others about it. Hyatt's excuse that it's hacky and not something they'd prefer to do misses the point completely as well -- why does Apple get to choose to use this functionality and not other developers?
No matter how people try to spin this, Apple leveraged internal knowledge and kept it to themselves to implement a feature into Webkit. That's wrong. Not "take you to court" wrong, but something they should address in the future.
Read the article and the subsequent comments. There is no public API to programmatically do this, it was obscured in a binary blob and not released publicly. A workaround which does something similar -- but not the same thing -- was public.
Actually, the XBOX still has not made any money, and probably never will because they chose to sell it at a loss. They expected to make up the difference in game sales, but that hasn't really worked out too well. This was a pretty stupid move on their part. XBOXes are NOT printers. They do not REQUIRE you to purchase supplies on a regular basis in order for it to continue to function.
The Xbox wasn't expected to make money, the Xbox 360 is expected to make money in the not-so-far future. Considering shrinking component costs, high sales, and ample games coming out, I don't see why that's not a possibility -- if not a probability.
And game consoles do require you to purchase games on a regular basis, effectively. The vast majority of gamers do buy games for their console on days other than the day they purchase their console.
I'm not sure why you could honestly say this was a stupid move on MS' part. The Xbox products are less about profit and more about defensive positioning against potential onslaughts on their monopoly from the living room. The PS3 with Linux on it is exactly why MS wants its Xbox in the living room, profit or not.
Business is a lot more complex than most/. geeks want to believe. If MS was concerned about making a profit only, I guarantee you they'd have less components in the 360 for a higher price.
It's absolutely vital that you check Vendor ID, Device ID, and Driver version in order to work around the countless bugs, quirks, and performance holes in all the well known broken systems out there (unless you absolutely want to slap a BIG 'only supported on Card X with (at least) Driver Y' STICKER on your packaging).
If you RTFA, you'd see that's really a thing of the past in DirectX 10.
The alpha automatically imported all data from the old bookmarks.html into the Places system. Firefox converted from IE to Mozilla's bookmarks.html already.
The later builds of the Alpha (last week or so) all included an Export functionality to dump your Places DB into a bookmarks.html file again for this next build. You can still download those builds if you need to export your Places DB to the old Bookmarks.html format.
This feature was cut from Firefox2 because it was unpolished and unacceptably buggy still. It is now on the "trunk" for inclusion in Firefox3, so it's still on the roadmap.
In fact, it remains enabled on the Trunk nightlies for Firefox3.
Slashdot Mirror
You're going to be in for a rude surprise.
OpenGL drivers on Windows are awful, DirectX is where all of the development effort goes on driver teams. At work we wrote our app using OpenGL for a 3D overlay because we ship on Windows, Mac, and Linux, but on Windows we took the time to write a DirectX backend instead of OpenGL and the stability and performance shot up noticably. OpenGL is a forgotten "checkbox feature" on Windows today, not much more.
The Xoom was half-baked and lacklustre, and no other tablet has been widely available for a reasonable amount of time.
That's all there is to it.
multi-touch is not a unique property of iPhone OS. My Nexus One is multi-touch, as is the Palm Pre/Pixi and so will be Windows Phone 7 devices.
Why not use system codecs? Because you're not solving the original problem. The problem was dependency on externally variable code that was frequently proprietary to render the web. Instead of requiring Flash to view websites in a default web browser, now we'll require K-Lite Codec Pack Max Extreme 2.0++?
Which codec would you use? Theora isn't implemented on most systems. h264 won't work on Windows by default (7 will, but that's just a small portion of the market). VC-1 won't work on Mac and Linux. MPEG-2 isn't even guaranteed to be found.
Congratulations...you've just opened a whole 'nother can of worms.
That's not true at all. Firefox, since 2.0, has had memory caching just like Opera does. Go to about:config and tweak how much is used (which is default-set based on your system capacity, just like Opera). It's called "browser.cache.memory.capacity".
I understand why they don't agree with the practice, but this is hardly front-page Slashdot news. The summary is, if anything, very misleading. This has NOTHING to do with Mozilla's plans for HTML5 or web openness, it's everything to do with some nameless blogger disagreeing with another nameless blogger's implementation of video fallback.
This is non-news, to say the least.
Some random Mozilla Hacks (note the word Hacks) blogger posts some code that web developers can use to implement HTML5 video (which does not use javascript, contrary to the implications in this article and summary?) and also provide a fallback path for non-HTML5 Video browsers (IE, Opera, etc). Their particular method of providing the fallback code uses javascript to determine browser capability, and uses Flash if HTML5 Video is not there.
Why is this upsetting to anyone? The implication from the summary is this is a less "open" way to do it, but last I checked Javascript/ECMAScript is a standard that all browsers implement already.
I cannot fathom why anyone would be so upset by some blogger providing JS-implemented video fallback implementations.
Firefox 3.5 implements the majority of those. IIRC Webkit and Safari are almost there too, and even MS is making a sprint to HTML 5 -- IE8 has started implementation there.
As for editors, yes -- they are under development.
Apple was far from the first company to implement multi-touch, it's just the first people think of. Multi-touch, and its patents, go back for quite a long time.
By definition, a superscalar processor does not need to be instruction re-ordering, speculative execution, or branch prediction. All a superscalar processor needs to do to be called superscalar is to dispatch more than one instruction per clock cycle to redundant functional units on the processor -- the 360's CPU is absolutely superscalar.
Incidentally, you are incorrect other aspects anyway: the Xenon cores DO have branch prediction, just in a significantly diminished capacity compared to what we're used to on the PC (small history tables, simpler logic, etc). The Cell's SPEs have none at all, and rely on "branch hints" instead where the programmer or compiler specifies which path may be likely at any given point. As a result, it also has speculative execution.
But you are correct in that the 360's CPUs -- like the Cell's PPU and SPEs -- is in-order and thus does not re-order instructions. It is up to the compilers to generate optimally ordered instructions, which isn't as big a deal as you may think on a closed-box system with optimized compilers. Back in '03-'04 I worked in IBM's compiler group on this very thing.
While it certainly sounds like you know what you're talking about, it's pretty clear to anyone with a game-dev background you do not.
Cell's SPEs are actually PRIMARILY used as aids to graphics processing (T&L) by most developers. Look into how games like Heavenly Sword use the SPEs as part of its "faux" HDR or games like Killzone 2 use SPEs to implement deferred rendering for awesome smoke effects. The SPEs are, in PRACTICAL TERMS to PS3 game developers, very essential to the 3D rendering side of the console.
While RSX is "powerful enough" to do its own T&L, it cannot compare to the standalone power of the 360's Xenos chip. There are many reasons for this (6 fixed vertex shaders on RSX vs the unified shaders on the 360 which permit far higher vertex workloads, to the RSX's limited bandwidth vs the 360's eDRAM bandwidth, to triangle setup rates). On the PS3, developers need to leverage Cell in intelligent ways to draw comparable graphics to the 360. If an intelligent and determined PS3 developer really leverages Cell, it can make unparalleled graphic in the console world. The problem is, it costs a fortune in time and money to do it and very few developers can. It's simply not worth it to even attempt it for most developers.
As a sidenote, Cell is not at all good for most game AI for many reasons (not the least of which is the lack of branch predictors in the SPEs).
Additionally, people keep making the mistake of assuming the PPU in the Cell is basically the same as each core in the 360's CPU. That's not at all true. There are some significant differences, including native Direct3D format support in the 360's CPU to the new VMX128 vector units (which have 128 registers per context per core [6 total], vs 32 on the PPU) as well as additional instructions specifically tailored towards 3D games (like single-cycle dot-product instructions). The combined triple VMX-128 units on the 360 are still faster than most quad-core Core i7 in vector processing, so I'm perplexed by the notion that it's somewhat slow or underpowered from what I've read from some people.
If you're truly interested in how PS3 games use Cell, check out the Beyond3D community where PS3 developers post in detail about how they do what they do. And Cell is a major factor in 3D rendering on the PS3. It has to be.
Surely not any more ridiculous than having to re-code your applications in Objective C and having to deal with Cocoa.
Not quite. When none of the browsers are getting 100/100 and the only browser to get over a 60 is a safari beta
The firefox nightlies (and upcoming beta 4) are getting 66/100.
I wouldn't say IE8 took the context-menus from Mail.app, if anything Mail.app stole smart tags from Office... Either way, if it's a handy feature, why not include it -- who cares who had it first.
As for the specific problem encountered in firefox, there is a perfectly acceptable and PUBLIC way of achieving the same thing,
This keeps being said, but it's not the same thing. The way FF got around it is on a Firefox-level XML-based fix. The way Webkit gets around it is a Webkit-level API-based fix.
Mozilla would like to do the same. Firefox is to Safari as Gecko is to Webkit. Gecko can and is embedded by other applications, and the optimal solution is to have this fixed in Gecko and not the container program.
Just how secret can it possibly be with publicly available release notes published years ago?
/. story is sensationalist (when are they not?), but that doesn't mean there's not an issue here. WebKit is using internal Apple knowledge of undisclosed functionality in OS X and not telling others about it. Hyatt's excuse that it's hacky and not something they'd prefer to do misses the point completely as well -- why does Apple get to choose to use this functionality and not other developers?
You are completely missing the point. There is no way to programmatically disable this with public knowledge, something Webkit did manage. All of the excuses on why no one else needs to do this except Webkit since it's embedded is nonsense -- Gecko is also embedded and can be used in other applications (and is used in other applications).
There's an API that is hidden in a binary blob to accomplish this. Apple chose not to make it public.
Yes, the
No matter how people try to spin this, Apple leveraged internal knowledge and kept it to themselves to implement a feature into Webkit. That's wrong. Not "take you to court" wrong, but something they should address in the future.
Read the article and the subsequent comments. There is no public API to programmatically do this, it was obscured in a binary blob and not released publicly. A workaround which does something similar -- but not the same thing -- was public.
Gecko can and is also embedded in any app. Both WebKit and Gecko are possible to be embedded, though Gecko is more popular for such use.
No, because quite clearly the PGO build is only a ~1s improvement over the non-PGO, which still spanks the competition.
And game consoles do require you to purchase games on a regular basis, effectively. The vast majority of gamers do buy games for their console on days other than the day they purchase their console.
I'm not sure why you could honestly say this was a stupid move on MS' part. The Xbox products are less about profit and more about defensive positioning against potential onslaughts on their monopoly from the living room. The PS3 with Linux on it is exactly why MS wants its Xbox in the living room, profit or not.
Business is a lot more complex than most
This is not true, either. Vista still ships with MS' PDF-esque format, just not PDF.
Adobe was concerned built-in PDF-authoring in Vista would kill sales of Acrobat Pro, so they threatened to sue MS for "abusing" its monopoly status.
It is still included as a feature in the "Trunk" branch for Firefox3.
The alpha automatically imported all data from the old bookmarks.html into the Places system. Firefox converted from IE to Mozilla's bookmarks.html already.
The later builds of the Alpha (last week or so) all included an Export functionality to dump your Places DB into a bookmarks.html file again for this next build. You can still download those builds if you need to export your Places DB to the old Bookmarks.html format.
This feature was cut from Firefox2 because it was unpolished and unacceptably buggy still. It is now on the "trunk" for inclusion in Firefox3, so it's still on the roadmap.
In fact, it remains enabled on the Trunk nightlies for Firefox3.