Would Objective-C improve performance?

There are plenty of advantages of using Lua based frameworks, which include things like no memory management (which is in some ways offered via ARC [Automatic Reference Counting]), fast access to creating objects and groups and creating interactive applications.

As an experiment, I wanted to see if I could use Objective-C and create the same hierarchy of Groups and images, etc. The nearest equivalents in Objective-C are UIViews and UIImageViews.

  UIView *grp = [[UIView alloc] initWithFrame:CGRectZero];
  [self.view addSubview:grp];
  return grp;

This would create a group (UIView) and add it to the hierarchy.

For creating an image, it could be written as

  UIImage * _img = [UIImage imageWithContentsOfFile:
                    [[NSBundle mainBundle] pathForResource:filename ofType:@"png"]];
  img = [[UIImageView alloc]initWithImage:_img];
  [group addSubview:img];

  return img;

In the code above group is the UIView (group) that we want the image to be a child of. We can either use self.view in a viewController which is the global view, the equivalent of the stage object.

Involved calling syntax

There are a couple of issues with the code, it works perfectly fine but it cannot be used like we are used to with Lua or C API's, it would still expect the objective-C type calling convention which would require this to be part of a class or the function to be called using the [self] object as

  -(void) newImage:(NSString *)filename parent:(UIView *)group
   {
    //Code here
   }

and to call it, you would use something like

  UIImageView * img = [self newImage:@"test" parent:self.view];

The problems with this are that you need to keep track of the objects created and you also have to convert between the different types of objects, UIView and UIImageView, etc.
Plus being used to a Lua/C type calling convention, we would want to have a function that we can simply call it like

  UIImageView *img = newImage("test", self.view)

Mix it up

For that, we would have to have a mix of C and Objective-C type of code and XCode can compile both C and Obj-C code for us together. We can simply declare functions that use the C convention, so instead of declaring the function as

  -(UIImageView *) newImage:(NSString *) filename parent:(UIView *) group
    {
      // Code
    }

we can declare it as

  id newImage(char * filename, id parent)
    {
      // Code 
    }

This is where we can also use the Objective-C runtime library which gives us access to the Objective-C library and classes via C type API.

So this bit of Objective-C code which we wrote above

  UIView *grp = [[UIView alloc] initWithFrame:CGRectZero];
  [parent addSubview:grp];
  return grp;

this can be written with the obj-C runtime library as

  id grp = objc_msgSend(objc_getClass("UIView"), sel_getUid("alloc")));
  grp = objc_msgSend(grp, sel_getUid("initWithFrame:"), CGRectZero);
  objc_msgSend(parent sel_getUid("addSubview:"), grp);
  return grp;

Viewports

While from an experimental point of view this works and if we add the setClipToBounds to true, it will also act like a viewport, masking the contents and not displaying anything that is outside of the viewport set.

Using Objective-C also offers some more advantages like CoreAnimation for smoother animation, it also offers the CATransforms and the CALayers that allow for generating some spectacular visual fx.

Relocating objects on screen

The way things get relocated in objective-C is by altering the frame of that visual object. If we set the frame for the UIView to CGRectZero which is basically a zero rect equivalent of CGRectMake(0,0,0,0). This rect works fine and child views can be added to this rect. However with visual objects, altering this will scale, reposition or flip the objects. So to reposition an object, we can simply alter the x and y of the structure as

  CGRect frame = theObj.frame;
  frame.origin.x = 100;
  frame.origin.y = 100;
  theObj.frame = frame;

What this does is it takes the frame object and overwrites the x and y and sets it back, this will thereby relocate the object to 100, 100. If the size.width or the size.height values were altered, this would have a bearing on the objects dimensions.

While the experiment continues, For basic Multimedia type applications, UIKit could be effective and provide a lot more functionality, what it really needs is a framework to tie it all together and contain the same.

Some goodies

Objective-C functions can be called by name simple by using

  [self performSelector:NSSelectorFromString(methodName)]

There are a lot of goodies, let's see if these can be put together for use as a lightweight fast and robust engine.

The advantage that I found is the final executables are very small, native, fast as there is no overhead framework code. Due to this not using the OpenGL as yet, it could have issues in trying to get the code cross platform, but all of the other iOS functionality is automatically added/available for free.