250 likes | 276 Views
This article discusses the process of porting ROOT's non-GUI graphics to iOS from a programmer's perspective. It covers topics such as using Objective-C/Objective-C++ to create a native GUI, working with the iOS architecture and frameworks, and addressing specific challenges of developing for iOS with ROOT.
E N D
iOS from programmers POV: iOS is Unix, but ... No X11 (no gVirtualX, no ROOT's GUI). No custom shared libraries (only system libraries), only static libraries for user (no CINT???). All ROOT is one static libROOT.a. Objective-C/Objective-C++ to create native GUI. Rich set of libraries and frameworks: CoreGraphics, CoreFoundations, CoreText, CoreAnimation, UIKit, GLES, etc. etc. Very specific GUI, different from Windows/X11/MacOS X. Fingers instead of mouse, touches instead of clicks, no cursor!
iOS, Mac OS, GLES related tasks: Port ROOT's non-GUI graphics to iOS Write ROOT-based native applications for iOS: a) demo of ROOT's graphics on iOS; b) browser for ROOT's files; c) components to support users, who want to develope for iOS with ROOT. Port our OpenGL code to GLES Native VirtualX back-end for Mac OS X HPC: head coupled perspective and its application for our Eve and OpenGL code
1. ROOT's non-GUI graphics (June): Mainly based on TVirtualPad interface (gPad). TPad/TCanvas internally calls TVirtualPadPainter methods (X11/Win32 GDI/OpenGL under the hood). To port it you can: re-implement TVirtualPad or extend TPad and implement TVirtualPadPainter for specific platform. I: implemented IOSPad: to keep the code as simple and clean as possible (TPad is already difficult to support); to add iOS-specific algorithms and extensions (not required in standard pad); to avoid TCanvas loop (TPad is a base for TCanvas, but it strongly depends on TCanvas (!!!). So IOSPad is responsible for primitive management and coordinate conversions, it also accepts all calls from the graphical primitives. implemented IOSPainter to do actual painting.
Graphics: implementation 2D graphics on iOS can be done by GLES or Quartz 2D (UIKit also). GLES has several problems: No tesselation (required to draw polygons and render text) No text rendering No built-in anti-alisaing for lines and polygons. Quartz 2D: Very rich 2D API (paths, strokes, blending, gradients, etc.) Advanced text rendering No problems with any polygons Anti-aliasing Can draw to a window, to bitmap, to PDF (the same code). etc. etc. So we decided to use Quartz 2D.
With CoreText (font metrics were improved, screenshots from real device)
Problems(2D graphics): Quartz (so cool) has nothing to work with font metrics (required by all ROOT's text primitives - labels, titles, pavestats etc. So text is now done by CoreText framework (and attributed strings from CoreFoundation framework). There is no Symbols font, used by ROOT. Custom fonts do not work for me at the moment (to be investigated) and they are very slow the first time you try to use such font (probably, iOS is doing some caching). Metrics are still not ideal. Optimize fill patterns (use bitmaps).
2. GUI on iOS - tools: UIKit (Cocoa Touch) - object oriented libraries, written in Objective-C, to be used from Objective-C or Objective-C++ (mixture of C++ and Obj-C). Model-view-controller pattern everywhere, reference counting everywhere. _VERY_ strange method names :) and memory management of stone age :) InterfaceBuilder to create user interface (Apple's analogue for QT-builder or ROOT's GUI builder, _VERY_ unusuall :) ). Mixture of CoreGraphics, CoreFoundation, QuartzCore and etc. libraries (unfortunately, you can not limit yourself with one UIKit, you have to use all this zoo of libraries).
Application on iOS consits of: UIApplication Run loop (done by UIKit) Window One or several controller objects Views, managed by controllers (views are rectangular areas, roughly speaking similar to TPad, but they contain not TObjects, but other views - widgets or sub-views).
"Tutorials": Split-view based application. Has several demos (something like demos.C from $ROOTSYS/tutorials) Supports zooming and scrolling (pinch gesture, taps, pan) Supports picking (initial version) Has editor prototype - in a popover window. 3D objects can be rotated with pan gesture Different animations. Mainly is a testbed for different features.
Problems: picking ROOT's picking requires very high precision, +- 2-4 pixels and you are not able to pick a histogram. Touches are very different from click - actual touch coordinates are always different (+- 10-20 pixels) from what you expect.
ROOT browser for iPad: Based on navigation controller and view hierarchie: top view to open/close select ROOT files (using TFile and TWebFile) view with file contents (with thumbnails for objects, contained in a file) detailed object view with IOSPad to draw object and editor to modify its properties (potentially with fit panel and etc.). This application is a simplified iOS mixture of TCanvas (with editor) and TBrowser (1% of TBrowser, of course :))
Problems to solve: UIScrollView is not good enough and works incorrectly for my browser. I have to develop a custom scroll-view. Work with files: big files, error handling, big number of objects, etc. Custom widgets and controls required for editors. Many editors to implement (I have only editors for TAttLine, TAttFill, TPad. Bugs :)
3. GLES (now only plans and estimation) GLES is a sibling of OpenGL, but it's very different from OpenGL 1.5 (Matevz estimate our OpenGL usage as it's a version 1.5): no fixed pipeline, it has to be written in GLSL (shaders). No display lists, no immediate mode (glVertex calls), we have to use vertex arrays or vertex buffer objects everywhere. GL painters for histograms I'll port easily, it will not take more than 3 weeks. Eve/GL-viewer part will be more complex.
4. VirtualX back-end for Mac OS X At the moment I can not estimate the time required. Will be Cocoa based (Objective-C++), since alternative - Carbon - is obsolete and deprecated (and there is no 64-bit version). Will reuse the code for iOS (since it's also Cocoa and Objective-C + Quartz and CoreXXX libraries).
5. HCP Main complexity is in (as I understand) pattern recognition methods and computer vision: using frontal camera (on iPad, or laptop, or external camera) a program has to trace head position in space and adjust perspective of 3D picture accordingly. I do not know at the moment, how difficult it is.