The patch is no longer required as Eric has helped by renaming the relevant classes when I was doing this year's GSoC project.
Sadly I don't know about the fonts issue; they should be drawn by Opal / Core Graphics. The relevant thing is done in the demo anyway, and not in QuartzCore code itself, so if you can figure out a way to draw fonts -- a patch will we very welcome :-) (This is because I cannot work on QC right now, so I can't look into the issue. I will help with my thoughts and advice in any way I reasonably can, though.) On Thu Jan 02 2014 at 9:40:20 AM, Tom Bruno <[email protected]> wrote: > I'm currently looking and interested in the quartzcore project. I've been > reading through the source and all the threads that I can find. I've been > able to compile, install & run the demos but have a few questions. I see > your notes about opal requiring your opal-nsfonthacks.patch. It seems this > patch can no longer apply. In addition to that issue, it also seems that > when I run all the demo fonts are not visible. I'm currently using > clang-3.4 and a self build of svn trunk for all modules/libs etc. > > Tom > > > On Dec 24, 2013, at 6:44 AM, Ivan Vučica <[email protected]> wrote: > > 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 > >
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
