I see a lot of the empty headers and .m files that I suppose represent the 
"unfinished" portion.  I'm curious as to how you came about the API/Headers 
that you would implement.  Some of these headers are only available on iOS 
platforms (CAEAGLLayer, CADisplayLink).  I read a post from while you were 
working on the project that said you were going to try and stay away from 
CoreVideo but things like QuartzCore/CVDisplayLink.h (the Mac Equiv to iOS's 
CADisplayLink.h) are part of CoreVideo.  The CVDisplayLink is a common way to 
drive the OpenGL frame drawing on OSX.

I guess what I'm trying to ask is what was your thinking and where were you 
headed with selecting CA* files that only exist on iOS, or was this just 
something that happened in passing?  I'm trying to get a feel for where you 
left off and were going.

 Tom

On Jan 2, 2014, at 12:15 PM, Ivan Vučica <[email protected]> wrote:

> 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

Reply via email to