Sunday, August 25, 2019

PSF GSoC students blogs: Panda3D iOS Support - A Postmortem

Hi everyone!

Well, it appears that this is the end of the line when it comes to my GSoC portion of my work. I got a huge amount of work done and am extremely proud of it, and I can't wait to continue working on this project in the coming months and make it the best it can be. This blog post is here to detail the work I completed over the summer, and also what I didn't have time to get to. So, let's begin!


Everything I completed

CMake Build Support

This actually ended up taking a lot of my time this summer (around a month). Currently, Panda3D uses a custom build system known as makepanda. Although this is a venerable and versatile build script, it was decided that a more standardized build system would be a better choice, so work began on replicating our current system with CMake. Because I began my iOS work before the CMake system was actually complete, this led to a couple of instances where I wasn't sure if there was an issue with my own code or with the Panda's experimental CMake implementation. In the end, however, thanks to CMake 3.14's new support for iOS devices, I was able to complete this task within the expected time frame.

eagldisplay

David Rose, who briefly worked on an iOS port (back when iOS was iPhoneOS), created the iphonedisplay module as an experimental method of running Panda apps. While this was a good starting point, I felt it was best to start from scratch considering the number of changes iOS has seen since the days of the iPhone 3G. This new display module should be easier to extend in the future when adding in a Metal backend, for example. Most of this is complete - there is support both for GraphicsWindows and GraphicsBuffers, along with some basic features such as autorotation.

PandaViewController

PandaViewController is a helper UIView that encapsulates the entirety of Panda on the Cocoa side of things. All one needs to do is specify where the Python source is, and PandaViewController will handle initializing Python and handing control to the Python script. I decided to go with this method of starting Panda mostly so existing apps can easily integrate Panda - it doesn't take over the main application loop or anything, so it quite very nicely with existing systems.

make_xcodeproj and makewheel.py

In addition to actually getting iOS support working, I also wanted to get started on the deployment process. Firstly, this required modifying makewheel.py to allow for the creation of wheels for iOS. This actually ended up being more complicated than I was first expecting, since makewheel had been designed to only generate wheels for the host system. I got it working in the end, though, and was able to begin churning out iOS-specific wheels. In addition, I had to add a new command to our setuptools-based deployment system that allows for the creation of Xcode projects, since that is the only way to test and deploy iOS apps on-device.

Multitouch (only partially)

I had gotten mouse emulation working well pretty early on in the project, since it was just a matter of converting touch events to the existing mouse events Panda is used to. Adding full-blown multitouch, however, has been much more of a challenge. Panda is not accustomed to handling multiple pointers (or anything other than a mouse, for that matter), so it took some changing at the architectural level, but I got a partial implementation working.


Stuff I didn't get to

DirectGUI touch support

This is something that I simply didn't have time for. It took me longer than expected to change Panda's architecture to allow for multiple pointers. While the DirectGUI widgets will indeed work, any touch specific gestures such as swiping to scroll are not present.

C++ app support

I had decided to prioritize getting Python working over C++, since the vast majority of Panda apps are written in Python. This should not be too difficult to accomplish; it should just be a matter of changing the entrypoint that PandaViewController uses when spawning a new thread.

Custom file handler for make_xcodeproj

Currently, make_xcodeproj just does a straight copy of all the game files, and ignores the custom handlers that can be specified in build_apps.

Documentation

Although I documented a lot of the code through comments, I failed to write any manual entries or longform docstrings. When I do this in the future, I would like to wait until we are filly migrated to the Sphinx manual instead of our custom MediaWiki stack.

Unit Tests

I never got to these simply because it would have taken a while to figure out what to actually test. As far as I know, there also isn't any good method of running tests on the C++ side of things; most of the existing unit tests utilize the generated Python bindings and call into the codebase from there.


What I could have done differently

Better communication with mentors

I did not talk to and consult with my mentors over Discord as much as I should have. I have a habit where I am hesitant to get feedback on my work unless it is in a somewhat completed state; I would end up telling myself, "I just need to finish up this one last feature/bug/whatever, then I'll push my work." And before I knew it, a week had passed by! This led to me dumping large changes all at once, which certainly was not helpful in quickly getting feedback.

Separation and organization of my work

I mainly used two branches for development: one called "cmake-ios" that I used to add CMake support and also write the display backend, and then a separate "multitouch" branch that is based from "cmake-ios". For my GitHub pull request, I ended up just merging everything into an "ios" branch, so a lot of different types of commit are all intertwined. There's not a lot of separation where someone can think to themselves, "oh, they added this feature in this commit, then continued working on it in this next commit". It's more like a developer with ADHD jumping around between features and bugs whenever they get noticed.


Although this is the end of my GSoC experience for this year, it is not the end of my work with Panda. I had already fixed a few bugs and gotten a few pull requests merged before I started this project, and I don't plan to stop that trend. Additionally, I am excited to continue my work on the iOS backend into the fall (on my own time, without a deadline looming over my head!). I am extremely happy with how everything has turned out so far, and am super excited to continue working with my mentors and everyone else in the community!

So long!



from Planet Python
via read more

No comments:

Post a Comment

TestDriven.io: Working with Static and Media Files in Django

This article looks at how to work with static and media files in a Django project, locally and in production. from Planet Python via read...