There was and there will not be any major migration to MAC for the simple reason that Apple (at least here in my country) was looked at as an Elite Hardware vendor with very high prices for what you get.
Continuing to answer that statement and at same time answering your point, my answer is based in your....people in MAC don't like the ports because the ports are of bad quality.
Now...who's to blame ? is really alone of who made the ports ? ....or is also because Apple continues to have a tight grip about their systems like the graphic about how the structure is implemented ? VC OEMs are responsible by a part....the other part is programmed by Apple....i doubt that things are really optimized as much as they could be...
When you have bad quality game ports, high prices for the hardware, with a brand that is the only one making the MACs and with a tight grip of what is sold and/or approved to that platform, it's bound to NEVER be more than a product for an Elite.
Cost... perhaps somewhat, although I know plenty of people who bought a Mac when they could have bought a cheaper Windows/whatever machine to do the same. They just like the Mac better and are willing to pay a bit extra for it.
Where a possible threshold for Mac might be price, I think usability is a threshold for linux. People aren't familiar with using a linux system, and many of their favourite applications may not be available. Macs are slightly closer to Windows, with things like Office, Photoshop, Premiere etc being available for both OSes.
I have ported my OpenGL code to OS X and iOS, and in both cases I had absolutely no issues with performance or compatibility (the common layer that Apple implements is only very minor anyway, and mainly used to set up the screen, the grunt rendering work is all done by the GLD).
I'm heading over to Valve HQ at the end of this month.
Can't wait to visit their Linux dev cabal (I already got the okay for that).
Also remember its not just the graphics part of the game you need to rip out to make a port, you also need to remove all those windows specific API calls, and I can assure you theres a LOT of them. So making a OGL to DX wrapper won't magically make everything ported to linux.
Some interesting comments (Q&A) from blog:
Iím interested to read that the rendering is achieved via a D3D > OpenGL abstraction layer, especially as it appears to be faster to do that than native D3D usage, that seems somewhat counter intuitive!
Iíd be interested to know though if your abstraction layer is generic enough that it could be applied with the same success to non-source-engine games, since that would be a nice big door to open, unless thatís something you donít wish to discuss right now! The prospect of an almost no-effort-needed wrapper that achieves native performance is a good one.Valve Linux team says:
Although the abstraction layer is currently quite powerful donít think of it as an ďalmost no-effort-neededĒ layer. A lot of time and effort was spent to get the layer (and L4D2) to the point it is today and we still arenít finished.Durandle says:
Is it overly simplistic to think of it as a library that exposes a DirectX API that converts to OpenGL on the fly?
(...) Would it be valid to compare what you are doing to be similar to what Transgamingís Cider does?Valve Linux team says:
Itís too early to answer those questions as weíre still learning a lot about Linux porting but it is our hope that this work will be useful for porting games besides L4D2.
When is the siggraph talk? I couldn't find the date on the siggraph site.