There's (hopefully!) no question of throwing it away already. That represents too much work, and pretty good design choices IMO. Yet I'm still pretty new to Pharo/Smalltalk so simply need time. At the moment I am only practicing on a GLFW binding. Now, I do believe in OpenGL and hardware rendering in general (vs software & framebuffer stuff), but these APIs are constantly evolving (with hardware, market needs, ...), with driver manufacturers having little care about backward compatibility. This means in that sea of innovations we have to spot the few key technologies which are going to last long enough to be still in use by the time they reach Pharo users (think of tesselation, or geometry shaders, hardly heard of nowadays). OpenGL ES 2 is such a key tech, I think, for its wide adoption in Android, iOS, RasPi. Still, there is no doubt it is going to be ditched too in a decade or so (command buffers are already being reintroduced in Vulkan...), and then in Pharo. With that in mind, my point is to make it as few and small classes as possible, to make it easier (and faster!) to ditch them later when a new key tech arises. That said, I'm looking for least effort solution, so will still strive to replace NB with UFFI in generator.
Cheers, Thibault > Why cutting things down to a subset? > You have all specs on Opengl.org .. all you have to do today is to import > xml file and generate proper ffi calls. You can, of course, add support of > OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't > have to use it if you don't need it. Instead, if that feels too big - you > can do it smarter way: > - make package/subpackage/classes for ES edition and for full edition. > It shouldn't cause much trouble if you do it right. > Because throwing away is easiest part - but making something that will > serve for years .. harder, because tomorrow someone else can come and throw > your stuff away :) > OpenGL is around for years now.. and i don't think ES edition will replace > standard.. I would prefer to be able to access to full OpenGL > functionality, at a day i will need it.. why cutting things down? > > There's many ways to do things in smart way so, nothing will be lost. > If you don't want/can't maintain or support full OpenGL support - that's > another story. Then just don't call your project OpenGL - it will cause > confusion to those who expecting things to work out of the box, and finding > out it just OpenGL ES.. > > > > My advise is don't worry about backward compatibility , make it easy, make > > it simple. Don't be afraid to code some of it in C if you have to. > > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > > > > Yep, make it work. That's all what matters.
