81–90 of 225 posts
:) Back in 2008 I helped JWZ port daliclock to the iPhone and once that was working I proposed a port of xscreensaver. He couldn't imagine ever wanting screensavers on an iPhone at the time. Guess he changed his mind. I also was the one that opened his eyes to the differences between OpenGL and OpenGL ES it seems. I apologize.
re: your username. Like retired basketball jerseys, shouldn't "quux" be reserved for Guy Steele?
It's not like there's this massive base of OpenGL code just waiting to be ported to embedded devices if there were just a few more API calls. Yes, there's glxgears, screensavers, and handful of open source games. You could probably get some old CAD programs to run on your Android. But if we compare the massive number of newly written OpenGL ES applications to all the old OpenGL 1.x fixed pipeline apps, the latter see…
Except he didn't port his code to OpenGL ES - he ported the missing API from OpenGL 1.3 to OpenGL ES. If it takes one developer three days to implement the missing API, then perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?
The latter is a far, far cry from the former. The former is basically what a modern OpenGL (non-ES) driver does to support all of the legacy cruft on modern hardware. Recall that the OpenGL API is an API for a state machine. All of those layers of cruft built up over the years have incredibly arcane state interactions, are a bitch to support, and are why modern OpenGL (non-ES) drivers have gotten rather quite bloated.
Edit: to tackle the second part of your comment:
> perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?
The Immediate Mode calls he complains about not being there? They were "removed" (never introduced) way back in OpenGL ES 1.0, which IIRC originally debuted in 2003.
It's a pretty big stretch to argue that because reimplementing Immediate Mode on top of OpenGL ES doesn't have a crushing performance penalty on 2012's iPhone, it wouldn't have been a problem on what passed for mobile hardware back in 2003.
(which is ignoring the fact that even if the performance back then wouldn't have been garbage, taking the opportunity to make breaking changes and throw out cruft for an API that wasn't expected to host legacy apps was absolutely the right move)
Earlier quoted context omitted.
Green text on a black background is very readable in normal lighting, yet doesn't assault the eyes if you are reading in a darkened room. In addition, there are still people using CRTs. Green on black is often clearer than white on black or black on white, especially in a small font, on CRTs because it is essentially monochrome, and so cannot suffer from fuzziness due to color misalignment.
FWIW, greenscreen (and amber) CRTs used green and amber phosphors; color alignment didn't come into it, right? As I understand it, green and amber because they were cheap.
I respect jwz, but this is very much a step backwards, and while I appreciate his complaint about breaking existing APIs, this would be for programs near 20 years old targeted at a different platform. OpenGL is a terrible, awful, crufty API, and the reason those methods were removed is that they are comically suboptimal. They do not reflect anything remotely like modern card capabilities, and their use directly cause…
jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…
I respect jwz, but this is very much a step backwards, and while I appreciate his complaint about breaking existing APIs, this would be for programs near 20 years old targeted at a different platform. OpenGL is a terrible, awful, crufty API, and the reason those methods were removed is that they are comically suboptimal. They do not reflect anything remotely like modern card capabilities, and their use directly cause…
jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…
It's incredibly daft to argue that part of a name amounts to a promise of backwards compatibility with a different API, in perpetuity. The X11 protocol isn't backwards compatible with that of X9 simply because they both share a name-fragment.
I respect jwz, but this is very much a step backwards, and while I appreciate his complaint about breaking existing APIs, this would be for programs near 20 years old targeted at a different platform. OpenGL is a terrible, awful, crufty API, and the reason those methods were removed is that they are comically suboptimal. They do not reflect anything remotely like modern card capabilities, and their use directly cause…
jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…
ES 1.1 still has alot of the old fixed function pipeline, but then in 2.0 they scrapped it all entirely, opting for a smaller, more modern API. That, to me, was a bad move. I think they should've made the shader based pipeline in 2.0 part of the 1.1 spec.
Earlier quoted context omitted.
jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…
But it's not OpenGL. It's OpenGL ES. Windows 8 is also not Windows 95.
Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.
I respect jwz, but this is very much a step backwards, and while I appreciate his complaint about breaking existing APIs, this would be for programs near 20 years old targeted at a different platform. OpenGL is a terrible, awful, crufty API, and the reason those methods were removed is that they are comically suboptimal. They do not reflect anything remotely like modern card capabilities, and their use directly cause…
jwz makes it clear that his deeper complaint is not about removing the cruft per se, it's about removing vast swaths of the API and then continuing to call it "OpenGL". If they'd called it "MobileGL" or some other nonsense, he probably wouldn't have liked the result (based on this rant), but he also wouldn't have complained that they broke working code. EDIT: 'continuing to call it "OpenGL"' -> 'using "OpenGL" in the…
The problem then, arguably, is not that OpenGL ES is called OpenGL but that OpenGL 2.0 added an entirely unrelated pipeline to that used in OpenGL 1.3: you could then claim "how dare they reuse the name for what is now two APIs stuck into one library". However, they shared a lot of underlying conventions, and they were honest about bumping the major version number.
If anything, the fact that jwz is happy he proved--that you can build an OpenGL 1.3 emulation library over OpenGL ES--would argue to me to /not/ include the 1.x features as part of the standard, but to instead encourage third parties to distribute such libraries. The fixed function pipeline wasn't removed from the API as it is unimplementable, but because it is a ton of obsolete code that 2.x coders avoid anyway.
Just some numbers, based on my hardware: Lion OS X install on disk: 7GB iOS 5.0.1 install: 1.7GB My MacBook's RAM: 8GB iPod Touch: 512KB MB's disk size: 100GB iPod Touch: 8GB So: Maybe they removed 80% of the API in general because the iPhone/iPod touch is only 10-20% of a normal computer? Something had to go.
jwz is complaining about OpenGL 1.3 support. It might be worth asking yourself what computers were like when OpenGL 1.3 was released (August 2001). P.S. I'm guessing your iPod touch has 512MB of RAM, not 512KB.