Hi Riccardo, On Mon Dec 23 2013 at 4:09:33 PM, Riccardo Canalicchio < [email protected]> wrote:
> Ok, I can help on the shaders field or the frame scheduling ( I'm not > really experienced with xorg) the upstream is on svn? I need to study the > current code... > Yes, all the code you want is on SVN. See the 'quartzcore' directory (we really need to rename this). > Do you have any paper of the overall design of CoreAnimation? > There is no such paper. It took me a while to figure out how best to implement Core Animation while staying compatible; in fact, that is an even more important part of my GSoC2012 work than the actual implementation itself. The implementation itself is the documentation, and I tried to iron out even the edge cases. Sadly, there are still cases where even the timing implementation that's in our code isn't fully compatible, but you'll notice that only in edge cases. And if someone is depending on Apple-compatible behavior, well, we can think about it when it's reported. > Currently gnustep seems to have not a roadmap but this project has one? > Not really, but it has a list of things you need if you want to make our implementation actually useful. > Just another question are you sure to use directly opengl? > I'm completely sure. > For example Clutter uses CoGL that wraps opengl and make a common api > between opengl and opengles; skia also supports both opengl and gles... i > have seen a lot of mails talking about uikit but opengl is not supported on > mobile... > Clutter is a scene manager, like Core Animation. Let's not include a middleware that doesn't need to be there. That goes for any other API wrappers; Core Animation API itself is a wrapper around OpenGL. Skia is, to the best of my knowledge, a Cairo and Core Graphics analogue, and deals primarily with rendering of 2D primitives. Core Animation deals with exposing compositing, 3D transforms and filtering to an Objective-C application in a nice API which supports implicit creation of CAAnimation objects. Skia could be used to provide content for CALayers, but there is no need to; we have Opal (our implementation of Core Graphics) for that. And regarding OpenGL not being supported on mobile, I'd advise you to compare the API of OpenGL and OpenGL ES. You'll see a lot of similarities. In fact, as David said, if you write OpenGL ES code, you need to do only minimum adaptations. At one point I had OpenGL ES compatibility in GNUstep's implementation of CA; I didn't test it in a long time by the time I wrapped up the GSoC project. In fact, it almost certainly doesn't work, considering that I added (very dumb and slow) shadow support by using shaders, which aren't supported in OpenGL ES 1.x, but are supported in OpenGL ES 2.0. The solution would be to transition to OpenGL ES 2.0, which would require use of (simple) shaders everywhere, as ES 2.0 tried to do away with as much of fixed function pipeline as possible; it's not a big deal, but it would take (only?) a few hours. On Tue, Dec 24, 2013 at 1:05 AM, Lundberg, Johannes < [email protected]> wrote: > Hi > > As you know, CG and CA is definitely a necessity for our project. As soon > as I can get my hands on someone who knows their ways around Open[GL/CL/VG] > etc I will put them to work on helping you implementing this in GNUstep :) > > -- > Johannes Lundberg > I'll be more than happy to provide initial planning and advice, as well as (pending positive resolution of some paperwork) code :-) OpenGL and OpenGL ES knowledge is probably enough, no need to worry about OpenCL and OpenVG.
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
