That's a very interesting result.
The failure it is talking about was codename "Longs Peak", a project that was supposed to be OpenGL 3.0. It was supposed to be a redesign from scratch but was eventually abandoned and OpenGL 3.0 was based on the old GL 2.0 API (with some parts deprecated and some new things added).
With the above said, 20% difference is solidly in the area of driver versions differences.
I'd be curious to see a less interested party doing the analysis. I'd like to get Carmack's or Sweeney's take on this. This feels like MS claiming that IE gets better perf than Chrome.
My recollection is that the performance increase came from a flaw in the renderer that was accidentally fixed in the OpenGL port.
There is no surprise. D3D is proprietary while OpenGL is open standard.
>It is by far the better of the two APIs
I highly disagree. Do you have any examples?
>Linux desktops is going to be based on Microsoft's RDP
What?? I've seen plenty of VNC in the wild, but yet to see any RDP
OpenGL is a dog's breakfast of an API. It's everything an API shouldn't be -- stateful, verbose, and committee-driven. Just take a look at Valve's .PDF.
An OpenGL programmer spends a large part of his/her time trying to maintain a mental model of the underlying driver's state and behavior. And God(s) help you if you step off the path used by popular applications and game engines. You can expect combinatorial bugs out the wazoo, again because the API and driver layers are so stateful.
I agree with the grandparent -- it's well past time that a D3D-like API was adopted by other players. I've used OpenGL since the Quake 1 days and I've never understood why so many people sing its praises. The days when D3D was an inferior API are more than a decade behind us.
OpenGL is cross-platform because it's legacy. It is primarily of interest to outdated CAD software vendors, because that's who's driving the API specs, hence why it took so long for the fixed-function pipeline to finally be dropped. Modern CAD vendors, such as Autodesk, render through a Direct3D pipeline.
but programming opengl still feels like setting up a rube goldberg machine for its initial run
I know that Wine implements some forms of compatibility, but it's not perfect.
Surely the risk would be that you could build DX11 for Linux but then DX12 moves all the goalposts again. Not to mention that there might be legal issues.
I wasn't aware that there was movement for RDP on Linux though.
> "This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model."
So looks like it could be an option in wayland, but not the only one.
Personal rant: Never mind that X11 does the same sorts of pixmap caching that RDP does to get its speed. Never mind that braindead toolkit developers render into offscreen local rectangles, and then transmit the entire rectangles as bitmaps into X, thus using none of this capability, which is why X is observed to be "slow" and "chatty". The conventional wisdom is that RDP is faster than X, so that's what we'll be using.
Meanwhile, Direct3D is quite a bit better than OpenGL, on a number of fronts.
Compare that to something like VNC which IIRC simply sends the screen data over as a raw bitmap and must rely on (potentially lossy) compression in order to get reasonable speed. This of course has the advantage that the client software needs to be much less intelligent to understand it and means that it needs much less deep OS integration.
This is why VNC clients and servers are available and can work easily between pretty much any platform.
The GP claims that X11 is capable of doing the same optimisations that RDP can do but this is not utilised well because the windowing toolkits such as GTK render their output to some other area of memory and X only gets to see the bitmapped result.
Not sure how teamviewer works, but I know some of these paid services use intermediaries to trasmit data over faster internet links to reduce latency but of course this costs them money so they have to charge you.
SO discussion here:
If the toolkit developers continue to render to bitmaps remoting on Linux will never be as fast as RDP for Windows.
In other words, it would have to become a lot more like Direct3D.
"Fixing" OpenGL to bring it into the current era of graphics development usually means making it look more like Direct3D anyway, so why not just go whole hog and adopt Direct3D?
You can't use that on the iOS devices, Android devices, OS X, Linux/Unix systems, PS3/PS4, Wii etc.
Only the PS3 has some OpenGL API support, but it is so bad most studios use libcgm, the lower level API.
«* gdb: debugging from 1970
* cgdb: debugging from 2000»
gdb is super-powerful but was a bit of a setback interface-wise because everything has to be done on a plain command line. And the GUI-based wrappers around it don't appeal to me much (don't know why, the ones I tried felt somewhat clunky).
But then again, I am an IDE kind of guy.
Seriously, DDD is pretty stable. People don't like it because it doesn't use Gtk+ or Qt. And the people who use it even if it looks ugly aren't the kind of people who would talk about it, they just use it.
Well, GNU/Linux may be open overall, but the NVIDIA drivers and in-house dev tools that are making all the magic happen certainly aren't.
I wonder why they are mainly using XP in china? Is it just that 7/8 are more difficult to pirate?