I would have thought the issues with perching the Surface were obvious from the moment photos of it appeared that showed how the stand worked. It might be fine on a desk but it would be a nuisance perched on the lap, or a small lecture hall table, or a clipback tray, or sitting in bed etc. Eventually Asus transformer devices will appear for Windows 8 Pro and I think at that point people can enjoy the best of both worlds - providing the keyboard dock counteracts the weight of tablet bit and doesn't tip over.
Just because some conspiracies are real does not mean they all are. And paranoia is an adequate explanation for many of the conspiracies floating around the kook-o-sphere.
Even if you strip away the non essential frameworks (i.e. the javax namespace), it's still a sizable chunk of code and pretty complex. And regardless of the OpenJDK being GPL or not, I bet the fear / threat of litigation ranks highly in the consideration of people thinking of using it in other open source projects.
JS would be a fairly lightweight, unencumbered library so it makes some sense to adopt it for app development if it were hooked up to some kind of visual development environment a la VB. QT did something similar with QTscript which is JS with extensions hooked up to QTDevelop. I expect the intention of GNOME is to facilitate a simple, visual editor which makes it easy to knock together apps.
Personally I think JS the language is horrible though. Just as VB was a terrible choice for novice programmers, so too is JS. I think Python would have been a better choice from that regard, but perhaps that too comes with its own baggage that ruled it out.
I was speculating that it was the only way to obtain acceptable performance through emulation, that QEMU could emulate the client side, thunk calls to Win32 which would be executed natively and then the response is thunked back into emulation again. If everything were emulated it would be horribly slow. If it were partially emulated then it would still be slow, but perhaps not unusably so especially with older apps which make less demands of the CPU.
Another option of course is to recompile with winelib and everything is native. Obviously that is the most desirable situation but it isn't viable for most games or commercial apps. Another might be something which disassembles the x86 code and recompiles the binary into equivalent ARM instructions but I wonder if this is even viable.
An ARM processor emulating x86 is not going to be fast in any circumstances. The best you could hope for is that everything on the other side of the Win32 API is native so only the client code is emulated. It might suffice for older Windows apps or games.
I like GNOME 3 and I think it gets far more criticism than it deserves. That said, there is a perception that a streak of elitism / arrogance runs through the project that they know better than anybody else and sometimes I think they could do well to listen to users a bit more.
I can't say I like Javascript as a language but at least its ubquitous and more modern, lightweight and flexible than some other candidates. It's also far better than something heavy like Java or god forbid Mono which bring a lot of baggage in terms of runtime size and potential lawsuits.
I'm wondering when the first device will appear which shows GUI elements even before the user has touched the screen. i.e. it senses the user moving their hand close to some portion of the screen and a hidden GUI associated with that area pops up in time to be there when they touch it. It'd have to be done carefully to avoid frustration but I think it'll come in time.
It was with the introduction of MagicGate and Minidisc that Sony began to lose its marbles. Somebody in that company must have given themselves a big pat on the back when they hobbled the hardware with DRM and ATRAC3. They probably thought the public would roll over and eat that shit up, but instead the public just shunned Sony and started buying from the competition who used more open industry standards.
I wouldn't be surprised if the media arm foisted this insanity on to the consumer electronics arm but it's all Sony as far as the end user is concerned. About the only ray of sanity in Sony was the PSP and PS3 which were pretty standards friendly and still are but even there it's not hard to see signs of interference. e.g. the PS3 has for the last 18 months or so enforced Cinavia audio watermarks which appear in some DVD and Blu Ray discs. Will it stop people ripping discs into media files? Of course not. Instead they'll just buy non-Sony kit to play it on. It's self defeating.
The Cg compiler can spit out GLSL. It's possible the GLSL is optimized for NVidia hardware but using Cg makes it portable to OpenGL or Direct3d. Tools like Unity use Cg for that reason.
Are you seriously suggesting that there are many OpenGL drivers which cannot adequately draw a polygon or quad even when presented with degenerate params? This stuff is old hat and has been part of the OpenGL spec since almost the beginning. Besides, even if you did force it in the app layer, why do you assume it would be any more reliable?
As for WebGL, I've voiced my own concern about WebGL, but since it's essentially OpenGL ES 2.0 with relatively minor differences I don't it's particularly relevant to the point I was making.
I don't doubt it's done in the driver. One reliable piece of code which has been tested to death which performs exactly as it says on the tin. It doesn't force apps to use it - they can use triangles if they want - but I see no reason to force them to use triangles if their geometry is something else to begin with.
I agree OpenGL ES 2.0 could do with some proper client side code for matrix calculations and so on. It's very frustrating to program in JOGL, or libgdx or Android and realise they all implement essentially the same stuff (e.g. they all have a column first matrix class) but in entirely different ways
I think pretty much everyone recognizes fixed function is toast. If you need that sort of thing then you probably need something higher level which expresses the world as a scene.
Show me any computer hardware (with the exception of vectrex etc.) which doesn't use pixels at the core. You can't. Everything uses pixels for a reason.
Just because a high level representation of a shape is decomposed into something else does not mean it's convenient to force an app through the lowest level. Forcing an app to decompose a mesh, quad or a poly into a fan, strip or individual triangles, including coping with all the degenerate cases is a needless development burden.
OpenGL ES 2.0 is meant for embedded devices where such a restriction might be a reasonable compromise. It isn't a reasonable compromise in a desktop where the GPU or the driver could do it far more reliably, efficiently and accurately than some random app.
OS/2 2.1 onwards were pretty easy to set up on non-IBM hardware. I didn't encounter a machine which didn't work with them. That said, OS/2 had so many other issues that hurt its own chances of success that someone could write an essay on the subject.
There is barely any abstraction at all in OpenGL ES 2.0. You load the GPU with shaders and tell it to render from buffers. There is no fixed function pipeline at all which undoubtedly comes as a "pleasant" surprise for anybody trying to port code to 2.0 from 1.1.
All the fixed function stuff is essentially deprecated and has been for a while. OpenGL ES 2.0 cuts it completely so it's unlikely that many game devs even pay it a passing glance any more.
I'm actively developing OpenGL ES 2.0 for android and one constant source of frustration is the quality of tools, documentation and examples. The tools are really bad since the nearest thing to syntax hilighting is the standard C editor and there is no way of telling if a shader will work or not without trial and error. The problem with documentation and examples is of another issue - there are so many different versions, bindings and implementations of OpenGL that it is very hard to find what you want in all the noise. You might come across a seemingly good example and discover it's no use because it's fixed function or uses the wrong version of GL.
I expect most developers wishing to target DirectX and OpenGL would write their shaders in Cg which is NVidia's proprietary shading language. The tool spits out the equivalent shader script in GLSL or HLSL.
Doesn't help much the other geometry stuff but I would not be surprised if the two APIs are largely analogous such that most of the differences can be abstracted away behind some utilities or some other for of separation, e.g. by using a 3rd party development platform like Unity.
OpenGL ES 2.0 might be suitable for running a desktop framework, but it probably isn't suitable for the apps running on top of it. It's too cut to the bone e.g. it only supports triangles, lines and points as primitives, lacks geometry and tesselation shaders and has various other restrictions which might be necessary in a phone but should not be when running against a PC GPU.
Anyway the full blown OpenGL with 4.x is somewhat getting its shit together and is a superset of ES 2.0 and 3.0. Just avoid the fixed function stuff and it should be fine.
Now... I just wish the documentation, tools and quality of drivers were all up to snuff for development. It's not uncommon to write a shader which works just fine on one driver but refuses to even compile on another. OpenGL needs a canonical, driver neutral set of compilers and tools which integrate into IDEs like Eclipse and reduce the hassle of development.
Slashdot Mirror
I would have thought the issues with perching the Surface were obvious from the moment photos of it appeared that showed how the stand worked. It might be fine on a desk but it would be a nuisance perched on the lap, or a small lecture hall table, or a clipback tray, or sitting in bed etc. Eventually Asus transformer devices will appear for Windows 8 Pro and I think at that point people can enjoy the best of both worlds - providing the keyboard dock counteracts the weight of tablet bit and doesn't tip over.
Not only grander but usually physically and logistically impossible. e.g. the people who assert controlled demolition for 9/11.
Just because some conspiracies are real does not mean they all are. And paranoia is an adequate explanation for many of the conspiracies floating around the kook-o-sphere.
JS would be a fairly lightweight, unencumbered library so it makes some sense to adopt it for app development if it were hooked up to some kind of visual development environment a la VB. QT did something similar with QTscript which is JS with extensions hooked up to QTDevelop. I expect the intention of GNOME is to facilitate a simple, visual editor which makes it easy to knock together apps.
Personally I think JS the language is horrible though. Just as VB was a terrible choice for novice programmers, so too is JS. I think Python would have been a better choice from that regard, but perhaps that too comes with its own baggage that ruled it out.
Another option of course is to recompile with winelib and everything is native. Obviously that is the most desirable situation but it isn't viable for most games or commercial apps. Another might be something which disassembles the x86 code and recompiles the binary into equivalent ARM instructions but I wonder if this is even viable.
An ARM processor emulating x86 is not going to be fast in any circumstances. The best you could hope for is that everything on the other side of the Win32 API is native so only the client code is emulated. It might suffice for older Windows apps or games.
I like GNOME 3 and I think it gets far more criticism than it deserves. That said, there is a perception that a streak of elitism / arrogance runs through the project that they know better than anybody else and sometimes I think they could do well to listen to users a bit more.
I can't say I like Javascript as a language but at least its ubquitous and more modern, lightweight and flexible than some other candidates. It's also far better than something heavy like Java or god forbid Mono which bring a lot of baggage in terms of runtime size and potential lawsuits.
Huff glue.
I'm wondering when the first device will appear which shows GUI elements even before the user has touched the screen. i.e. it senses the user moving their hand close to some portion of the screen and a hidden GUI associated with that area pops up in time to be there when they touch it. It'd have to be done carefully to avoid frustration but I think it'll come in time.
Didn't you know? They paved paradise and put up a parking lot.
I wouldn't be surprised if the media arm foisted this insanity on to the consumer electronics arm but it's all Sony as far as the end user is concerned. About the only ray of sanity in Sony was the PSP and PS3 which were pretty standards friendly and still are but even there it's not hard to see signs of interference. e.g. the PS3 has for the last 18 months or so enforced Cinavia audio watermarks which appear in some DVD and Blu Ray discs. Will it stop people ripping discs into media files? Of course not. Instead they'll just buy non-Sony kit to play it on. It's self defeating.
The Cg compiler can spit out GLSL. It's possible the GLSL is optimized for NVidia hardware but using Cg makes it portable to OpenGL or Direct3d. Tools like Unity use Cg for that reason.
I don't profess to have tried every brand of PC, but I had no trouble installing OS 2.1 and Warp on random OEM boxes in work and at home that I tried.
Please grow up.
As for WebGL, I've voiced my own concern about WebGL, but since it's essentially OpenGL ES 2.0 with relatively minor differences I don't it's particularly relevant to the point I was making.
I agree OpenGL ES 2.0 could do with some proper client side code for matrix calculations and so on. It's very frustrating to program in JOGL, or libgdx or Android and realise they all implement essentially the same stuff (e.g. they all have a column first matrix class) but in entirely different ways
I think pretty much everyone recognizes fixed function is toast. If you need that sort of thing then you probably need something higher level which expresses the world as a scene.
Just because a high level representation of a shape is decomposed into something else does not mean it's convenient to force an app through the lowest level. Forcing an app to decompose a mesh, quad or a poly into a fan, strip or individual triangles, including coping with all the degenerate cases is a needless development burden.
OpenGL ES 2.0 is meant for embedded devices where such a restriction might be a reasonable compromise. It isn't a reasonable compromise in a desktop where the GPU or the driver could do it far more reliably, efficiently and accurately than some random app.
OS/2 2.1 onwards were pretty easy to set up on non-IBM hardware. I didn't encounter a machine which didn't work with them. That said, OS/2 had so many other issues that hurt its own chances of success that someone could write an essay on the subject.
There is barely any abstraction at all in OpenGL ES 2.0. You load the GPU with shaders and tell it to render from buffers. There is no fixed function pipeline at all which undoubtedly comes as a "pleasant" surprise for anybody trying to port code to 2.0 from 1.1.
All the fixed function stuff is essentially deprecated and has been for a while. OpenGL ES 2.0 cuts it completely so it's unlikely that many game devs even pay it a passing glance any more.
I'm actively developing OpenGL ES 2.0 for android and one constant source of frustration is the quality of tools, documentation and examples. The tools are really bad since the nearest thing to syntax hilighting is the standard C editor and there is no way of telling if a shader will work or not without trial and error. The problem with documentation and examples is of another issue - there are so many different versions, bindings and implementations of OpenGL that it is very hard to find what you want in all the noise. You might come across a seemingly good example and discover it's no use because it's fixed function or uses the wrong version of GL.
Doesn't help much the other geometry stuff but I would not be surprised if the two APIs are largely analogous such that most of the differences can be abstracted away behind some utilities or some other for of separation, e.g. by using a 3rd party development platform like Unity.
Anyway the full blown OpenGL with 4.x is somewhat getting its shit together and is a superset of ES 2.0 and 3.0. Just avoid the fixed function stuff and it should be fine.
Now... I just wish the documentation, tools and quality of drivers were all up to snuff for development. It's not uncommon to write a shader which works just fine on one driver but refuses to even compile on another. OpenGL needs a canonical, driver neutral set of compilers and tools which integrate into IDEs like Eclipse and reduce the hassle of development.