GSoC 2018. is over.

It was a bumpy ride. But before I share my overall thoughts and experiences, let me update you with the project.

The project page at GSoC website can be found here.

Here goes the summary of the project (copypasta of my official project submission):

1. Project goals (taken from proposal)

Although GNUstep has an implementation of both AppKit and CoreAnimation, they are not integrated. The
goal of the project would be to allow AppKit’s views to draw into Core Animation layers, and therefore to be
better animatable.

The main goal would be to implement automatic creation of CALayer tree from the existing NSView tree, as well as to implement creation of a CARenderer and OpenGL view in the appropriate place.

2. Project status

Unfortunately I have not managed to completely finish the project due to a mysterious bug somewhere in Opal (more on that later).

2.1 Finished tasks

  • Created new class GSCAData which holds data neccesarry to implement core animation methods on NSViewinstances
  • Implement setWantsLayer, getWantsLayer, makeBackingLayer
  • Implement GNUstep specific methods: _gsAddCARenderer, _gsRemoveCARenderer, _gsCreateOpenGLContext, _gsSetOpenGLContext

With all of the above methods implemented, you can currently create a CALayer tree that backs the NSView subtree of the initial instance that recieved setWantsLayer(YES).

You can also attach/remove a CARenderer instance to the NSView in question.

This system was proven to work when I managed to draw some custom graphics into a CALayer instance,
which is then drawn into a NSView-managed OpenGLcontext.

The issues started when I wanted to get the actual NSView contents drawn into its corresponding CALayer(instead of some custom graphics).

With graphicsContextWithCGContext:flipped:method I did manage to "convert" the Core Graphics context which CALayer is provided with to a NSGraphicsContext in which NSViewcan draw its contents with a call to displayRectIgnoringOpacity:inContext: method.

However, it simply doesn't draw. I've spent last couple of weeks trying to find the cause of this. My mentors Ivan and Fred helped a lot, but we have had no success.

2.2 The bug that prevents the drawing

The issue is present during a call to displaIgnoringOpacity:inContext: method on NSView. All the code in that method works correctly. All the contexts that are eventually passed to it are being used correctly. The issue may be that something is "reseting" the global context to the context of the window, thus rendering in the wrong place. The issue was followed back to the DPSrectfill function inside of the Opal backend, where it finally draws into the wrong context.

After hours and hours of staring in gdb, the cause of this issue is still not clear.

2.3 Unfinished tasks

Currently the project sits at ~80% completion. If the stated bug gets fixed, it is just a couple of days work to finish the project.

It remains to implement automatic creation of CARenderer instance in the right place, and to handle/synchronise the CALayer tree if the NSView tree changes after the initial call to setWantsLayer:YES.

3. Additional info

The project currently lives as a folder in the libs-quartzcore library.

Some of the work that didn't make it can be found in my fork.

Spreadsheet containing commits

If you wish to, you can download the .tar.gz archive of the project files here (from my fork).

You can also read my blog posts which contain more technical details and can be found here.

My thoughts on GSoC

Allright, after briefing you with the state of the project, let me share some thoughts on GSoC itself.

First of all, the application/proposal guidelines are very distant from reality. I wrote the first version of my proposal strictly following gsoc guidelines for writing proposals. After getting some input from people that finished GSoC in the past, my end proposal was totally different from the first version. Eh.

Second of all, the mailing list for students is ****. There is a ton of people spamming irrelevant things, ex: "my adress doesn't fit in 20 chars which is the limit on the website". Thoose questions are not ment for the public list, they should be directed privately at GSoC organizers. To make matters worse, the same question gets asked repeatedly and you end up with 10 new emails each day, all of which are irrelevant. I know that Google is not directly responsible for this, but they could police a bit more and direct people to send direct messages at them, instead of the entire mailing list.

Third, the organisation aspect of GSoC (the host of GSoC is Google). I really do appretiate all the effort and would like to see GSoC continue for years to come, but Google Open source team could improve some things on their side. For example, the web dashboard (and the emails generated by it) are the main way of communicating "with the program". And yet, there were at least a couple of bizzare mistakes from the organizers side. Last instance of this happened a couple of days ago. All GSoC-ers who successfully finished the program get a t-shirt. To get yours, you are sent an mail with a link to the shirt provider and a one-time code to redeem your shirt. Except there was no code. Some students didn't get the code. How cool is that. And there were (if I recall correctly) 2 simmilar instances like this one this year. Please, test your apps before deploying them. I don't feel like I should be saying this to you, Google.

But I can't really bash on the organizers, since they are putting enormous effort into GSoC and without them it wouldn't be what it is today - a great learning experience.

Bye GSoC (see you next year?)
Stjepan