--- /dev/null
+Android
+=======
+
+Prerequisites
+-------------
+
+_Currently we only support building Skia for Android on a Linux or Mac host!_
+
+The following libraries/utilities are required in addition to those needed for a standard skia checkout:
+
+ * Apache Ant
+ * The Android SDK: http://developer.android.com/sdk/
+
+~~~~
+$ sudo apt-get install ant git
+~~~~
+
+Check out the source code
+-------------------------
+
+Follow the instructions [here](../download) for downloading the Skia source. Modify .gclient to add the following line to
+the bottom, and then run gclient sync again:
+
+ target_os = ["android"]
+
+Inside your Skia checkout, `platform_tools/android` contains the Android setup
+scripts, Android specific dependencies, and the Android Sample App.
+
+Setup the Android SDK
+---------------------
+
+To finish setting up the Android SDK you need to download use the SDK to
+download the appropriate API level. To do this simply go to the directory
+where you installed the SDK and run the following commands
+
+ # You may want to add this export to your shell's .bash_profile or .profile
+ export ANDROID_SDK_ROOT=/path/to/android/sdk
+
+ $ ANDROID_SDK_ROOT/tools/android update sdk --no-ui --filter android-19
+
+From here you will need to type 'y' to approve the license agreement and that
+is all. You will then have downloaded the SDK for API level 19 (Android 4.4
+KitKat) which will be used to build the Skia SampleApp. You can download as
+many other Android add-ons or APIs as you want, but you only are required to
+have this one in order to complete the Skia build process.
+
+Setup Environment for Android
+-----------------------------
+
+The Android build needs to set up some specific variables needed by both GYP
+and Make. We make this setup easy for developers by encapsulating all the
+details into a custom script that acts as a replacement for make.
+
+Custom Android Build Script
+---------------------------
+
+The android_ninja script is a wrapper for the ninja command (provided by
+depot_tools) and is specifically designed to work with the Skia's build
+system. To use the script you need to call it from Skia's trunk directory with
+the -d option plus any of the options or arguments you would normally pass to
+ninja (see descriptions of some of the other flags here).
+
+ export ANDROID_SDK_ROOT=/path/to/android/sdk
+ export PATH=$PATH:/path/to/depot_tools
+
+ cd skia
+ ./platform_tools/android/bin/android_ninja -d nexus_10 # or nexus_7, galaxy_nexus, etc...
+
+The -d option enables the build system to target the build to a specific
+architecture such as MIPS (generic), x86 (generic) and ARM (generic and device
+specific flavors for Nexus devices). This in turn allows Skia to take
+advantage of specific device optimizations (e.g. NEON instructions).
+
+Generate build file from GYP
+----------------------------
+
+We use the open-source gyp tool to generate build files from our multiplatform
+"gyp" files. While most other platforms enable you to regenerate these files
+using `./gyp_skia` it is recommend that you do NOT do this for Android. Instead
+you can rely on it being run automatically by android_ninja.
+
+Faster rebuilds
+---------------
+
+You can use ccache to improve the speed of rebuilding:
+
+ # You may want to add this export to your shell's .bash_profile or .profile
+ export ANDROID_MAKE_CCACHE=[ccache]
+
+Build and run executables on the device
+---------------------------------------
+
+The build system packages the Skia executables as shared libraries. As such,
+in order to run any executable on the device you must install the library and
+a launcher executable on your device. To assist in this process there is a
+script called `android_run_skia` that is located in the
+`platform_tools/android/bin` directory.
+
+Run correctness tests
+---------------------
+
+First build the app and then run it on an attached device:
+
+ ./platform_tools/android/bin/android_ninja [-d device_id] dm
+ ./platform_tools/android/bin/android_run_skia dm # uploads and runs the dm binary on the attached device
+
+Run performance tests
+---------------------
+
+Since nanobench tests performance, it usually makes more sense to run it in
+Release mode.
+
+ BUILDTYPE=Release ./platform_tools/android/bin/android_ninja [-d device_id] nanobench
+
+ # uploads and runs the nanobench binary on the attached device
+ ./platform_tools/android/bin/android_run_skia --release nanobench
+
+If you pass nanobench SKP files, it will benchmark them too.
+
+ ./platform_tools/android/bin/[linux/mac]/adb push ../skp <dst> # <dst> is dir on device
+
+Finally to run the executable there are two approaches. The simplest of the
+two run the app on the device like you would do for gm or tests, however this
+approach will also produce the noisiest results.
+
+ # <input> is file/dir on device
+ ./platform_tools/android/bin/android_run_skia --release nanobench --skps <input>
+
+Build and run SampleApp
+-----------------------
+
+The SampleApp on Android provides a simple UI for viewing sample slides and gm images.
+
+ BUILDTYPE=Debug ./platform_tools/android/bin/android_ninja -d $TARGET_DEVICE
+
+Then, install the app onto the device:
+
+ ./platform_tools/android/bin/android_install_apk
+
+Finally to run the application you must navigate to the Skia Samples
+application using the application launcher on your device.
+
+Build tools
+-----------
+
+The Android platform does not support skdiff at this time.
+
+Clean up all generated files
+----------------------------
+
+ make clean
+
+Debugging on Android
+--------------------
+
+We support debugging on using a GDB wrapper script. The script loads the app
+onto the device, starts a gdbserver instance with that app, and then enters a
+GDB client shell on the host. Necessary symbol files are pulled from the
+device and placed into a temporary folder. The script does not build the app -
+you'll have to do that first.
+
+ # you can include additional arguments in quotes (e.g. "dm --nopdf")
+ ./platform_tools/android/bin/android_gdb_exe dm
+
+When the gdb client is ready, insert a breakpoint, and continue to let the
+program resume execution.
+
--- /dev/null
+Quick Start Guides
+==================
+
--- /dev/null
+iOS
+===
+
+Prerequisites
+-------------
+
+_These steps should closely follow building on Mac OS X. Those steps seem slightly out of date._
+
+Build and run SampleApp in the XCode IDE
+----------------------------------------
+
+### XCode 4.5
+
+
+To build SampleApp on XCode 4.5 using the IDE these steps should work:
+
+ GYP_DEFINES="skia_os='ios' skia_arch_type='arm' armv7=1 arm_neon=0" ./gyp_skia
+ xed out/gyp/SampleApp.xcodeproj # opens the SampleApp project in the IDE
+
+Note that if you run make at the command line the gyp\_skia script will rerun
+and you'll lose the effect of the GYP\_DEFINES. To avoid this do:
+
+ export GYP_DEFINES="skia_os='ios' skia_arch_type='arm' armv7=1 arm_neon=0"
+
+### XCode 3
+
+Use GYP\_DEFINES to tell gyp\_skia how to build for iOS. Here's a bash shell
+snippet that sets the world up to build SampleApp with XCode 3:
+
+ function buildSampleApp()
+ {
+ sdkVersion="4.3"
+ if [[ "$1" == "sim" ]] ; then
+ export GYP_DEFINES="skia_os='ios' skia_arch_type='x86' \
+ ios_sdk_dir='/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator' \
+ ios_sdk_version='$sdkVersion'"
+ elif [[ "$1" == "iphone" ]] ; then
+ export GYP_DEFINES="skia_os='ios' skia_arch_type='arm' armv7='1' arm_neon='0' \
+ ios_sdk_dir='/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS' \
+ ios_sdk_version='$sdkVersion'"
+ elif [[ "$1" == "mac" ]] ; then
+ export GYP_DEFINES=""
+ else
+ echo "buildSampleApp expects 'sim', 'iphone', or 'mac'"
+ fi
+ if [[ "$1" == "sim" ]] || [[ "$1" == "iphone" ]] || [[ "$1" == "mac" ]] ; then
+ save=`pwd`
+ cd /chrome/nih/skia/trunk
+ echo "$GYP_DEFINES ./gyp_skia gyp/SampleApp.gyp"
+ ./gyp_skia gyp/SampleApp.gyp
+ cd $save
+ fi
+ if [[ "$1" == "sim" ]] ; then
+ setiossdk iphonesimulator$sdkVersion
+ elif [[ "$1" == "iphone" ]] ; then
+ setiossdk iphoneos$sdkVersion
+ fi
+ }
+
+The script function setiossdk called by buildSampleApp is a
+not-completely-working hackery. When gyp builds an iOS-targeted project, it is
+hard-coded for the iOS simulator. To point the project at either the iOS
+simulator, or an iOS device, the project file must be opened to create a
+custom pbxuser file.
+
+This is accomplished by:
+
+ function setiossdk()
+ {
+ osascript -e 'tell app "Xcode" to quit'
+ osascript -e 'repeat until appIsRunning("Xcode") is false' -e \
+ 'do shell script "sleep 1"' -e 'end repeat'
+ save=`pwd`
+ skia
+ cd out/gyp
+ for project in *.xcodeproj; do
+ open $project
+ done
+ osascript -e 'tell app "Xcode" to quit'
+ osascript -e 'repeat until appIsRunning("Xcode") is false' -e \
+ 'do shell script "sleep 1"' -e 'end repeat'
+ for project in *.xcodeproj; do
+ lsave=`pwd`
+ cd $project
+ filename=`eval whoami`.pbxuser
+ while [[ ! -s $filename ]] ; do
+ sleep 1
+ echo -n "."
+ done
+ sed -e '/activeSDKPreference/ d' <$filename | sed -e '/activeTarget/ i\
+ \ activeSDKPreference = '$1';' >x$filename
+ if [[ -s x$filename ]] ; then
+ mv x$filename $filename
+ else
+ echo "mv x$filename $project/$filename failed"
+ fi
+ cd $lsave
+ done
+ open SampleApp.xcodeproj
+ cd $save
+ }
+
+In particular, the calls to osascript to wait for Xcode to quit use faulty syntax.
+
--- /dev/null
+Mac OS X
+========
+
+Prerequisites
+-------------
+
+Make sure the following have been installed:
+
+ * XCode (Apple's development environment): required
+ * publicly available at http://developer.apple.com/xcode/
+ * add the optional Unix Tools to the install so you get the make command line tool.
+ * Chromium depot_tools: required to download the source and dependencies
+ * http://www.chromium.org/developers/how-tos/depottools
+
+Check out the source code
+-------------------------
+
+See the instructions [here](../download).
+
+Generate XCode projects
+-----------------------
+
+We use the open-source gyp tool to generate XCode projects (and analogous
+build scripts on other platforms) from our multiplatform "gyp" files.
+
+Before building, make sure that gyp knows to create an XCode project or ninja
+build files. If you leave GYP_GENERATORS undefined it will assume the
+following default:
+
+ GYP_GENERATORS="ninja,xcode"
+
+Or you can set it to `ninja` or `xcode` alone, if you like.
+
+You can then generate the Xcode projects and ninja build files by running:
+
+ ./gyp_skia
+
+Build and run tests from the command line
+-----------------------------------------
+
+ ninja -C out/Debug dm
+ out/Debug/dm
+
+The usual mode you want for testing is Debug mode (SK_DEBUG is defined, and
+debug symbols are included in the binary). If you would like to build the
+Release version instead:
+
+ ninja -C out/Release dm
+ out/Release/dm
+
+Build and run nanobench (performance tests)
+-------------------------------------------
+
+In this case, we will build with the "Release" configuration, since we are running performance tests.
+
+ ninja -C out/Release nanobench
+ out/Release/nanobench [ --skps path/to/*.skp ]
+
+Build and run SampleApp in the XCode IDE
+----------------------------------------
+
+ * Run gyp_skia as described above.
+ * In the Finder, navigate to $SKIA_INSTALLDIR/trunk/out/gyp
+ * Double-click SampleApp.xcodeproj ; this will launch XCode and open the SampleApp project
+ * Click the “Build and Run” button in the top toolbar
+ * Once the build is complete, you should see a window with lots of shaded text examples. To move through the sample app, use the following keypresses:
+ * right- and left-arrow keys: cycle through different test pages
+ * 'D' key: cycle through rendering methods for each test page
+ * other keys are defined in SampleApp.cpp’s SampleWindow::onHandleKey() and SampleWindow::onHandleChar() methods
--- /dev/null
+NaCl (Experimental)
+===================
+
+Important Notes
+---------------
+
+ * This process has only been verified to work on Linux
+ * Skia for NaCl is new and currently under development. Therefore, some features are not (yet) supported:
+ * GPU backend
+ * Fonts - Currently, NaCl has no way to access system fonts. This means
+ that text drawn in Skia will not display. A Pepper font API is in the
+ works and should be available in the near future, but for now your best
+ bet is to either package font data with your nexe or to send font data
+ from javascript to your plugin at runtime. Note that this will be the
+ case with any graphics library in NaCl until the font API is finished.
+
+Prerequisites
+-------------
+
+Execute the following commands in whatever directory you want to hold the NaCl SDK directory:
+
+ wget http://storage.googleapis.com/nativeclient-mirror/nacl/nacl_sdk/nacl_sdk.zip
+ unzip nacl_sdk.zip
+ rm nacl_sdk.zip
+ nacl_sdk/naclsdk update pepper_32
+ export NACL_SDK_ROOT=/path/to/nacl_sdk
+
+Check out the Skia source
+-------------------------
+
+We use the "gclient" script (part of the depot_tools toolkit) to manage the
+Skia source code. Follow the instructions at
+http://www.chromium.org/developers/how-tos/depottools to get the gclient
+script from depot_tools.
+
+Instead of checking out trunk directly you will use gclient to checkout the
+nacl directory, which will automatically pull the trunk directory for you.
+Execute the following commands in whatever directory you want to be the root
+for your Skia on NaCl development:
+
+ gclient config https://skia.googlesource.com/skia.git
+ gclient sync
+
+Building the Skia libraries for NaCl
+------------------------------------
+
+The nacl_make script is used to compile Skia targets for NaCl. It sets the
+appropriate environment variables, calls GYP to generate makefiles, and runs
+Make to build both 32 and 64-bit targets as required by NaCl. To build the
+Skia libraries, run the following from the trunk directory:
+
+ platform_tools/nacl/nacl_make skia_lib
+
+This will result in a set of static libraries being built into the out/nacl32
+and out/nacl64 directories. You can use these libraries in external NaCl
+apps.
+
+Building and running Skia's Apps in NaCl (Experimental)
+-------------------------------------------------------
+
+It is possible to run some of Skia's console apps in the browser.
+
+### Skia Unit Tests
+
+Build Skia tests from the trunk directory:
+
+ platform_tools/nacl/bin/nacl_make tests
+
+This will build the tests executable. We include a tiny HTTP server (borrowed
+from the NaCl SDK) in order to run the apps:
+
+ cd platform_tools/nacl
+ ./httpd.py
+
+The HTTP server runs on port 5103 by default. In Chrome, navigate to
+`http://localhost:5103/` and click on the link for "unit tests." After the
+module downloads, you should see the tests begin to run.
+
+### Sample App
+
+The sample app relies on the GPU backend. Therefore, it will compile but will not yet run.
+
+ platform_tools/nacl/bin/nacl_make SampleApp
+
+You can access the sample app at http://localhost:5103/SampleApp.
+
+### Debugger
+
+The debugger is currently in a partially-working state:
+
+ platform_tools/nacl/bin/nacl_make debugger
+
+You can access it at http://localhost:5103/debugger.
--- /dev/null
+Windows
+=======
+
+Prerequisites
+-------------
+
+Make sure the following have been installed:
+
+ * Visual C++ 2013 Express or later, available for free
+ * http://www.visualstudio.com/downloads/download-visual-studio-vs#d-express-windows-8
+
+ * Chromium depot_tools
+ * http://www.chromium.org/developers/how-tos/depottools
+ * git
+ * Either use the mysygit installed by depot_tools
+ * Or install msys git: http://msysgit.github.io/ yourself
+ * Python 2.7.x (if you're not planning to use cygwin)
+ * available for free download at http://www.python.org/download/releases/
+ * make sure the installer changes your %PATH% environment variable to include the directory with the "python.exe" binary
+ * Cygwin (optional, but useful if you want to use git)
+ * Download from http://cygwin.org/setup.exe
+ * use any mirror you like; http://lug.mtu.edu works well
+ * Cygwin installs a minimum of options. Add these packages if they aren't already selected:
+ * Devel git
+ * Devel subversion
+ * Editors vim
+ * to fix arrows in insert, copy /usr/share/vim/vim73/vimrc_example.vim to ~/.vimrc
+ * Net ca-certificates
+ * Python python
+ * Utils patch
+ * Utils util-linux
+ * set the windows envionment variable CYGWIN to nodosfilewarning
+
+Check out the source code
+-------------------------
+
+see https://sites.google.com/site/skiadocs/developer-documentation/contributing-code/downloading
+
+Generate Visual Studio projects
+-------------------------------
+
+We use the open-source gyp tool to generate Visual Studio projects (and
+analogous build scripts on other platforms) from our multi-platform "gyp"
+files.
+
+You can generate the Visual Studio projects by running gyp_skia, as follows:
+
+ cd %SKIA_CHECKOUT_DIR%
+ python gyp_skia
+
+This will produce Visual Studio projects in the `%SKIA_CHECKOUT_DIR%\out` directory.
+
+Build and run tests from the command line
+-----------------------------------------
+
+ ninja -C out\Debug dm
+ out\Debug\dm
+
+Normally you should run tests in Debug mode (SK_DEBUG is defined, and debug
+symbols are included in the binary). If you would like to build the Release
+version instead:
+
+ ninja -C out\Release dm
+ out\Release\dm
+
+Build and run tests in the Visual Studio IDE
+--------------------------------------------
+
+ * Generate the Visual Studio project files by running gyp_skia as described above
+ * Open a File Explorer window pointing at the %SKIA_CHECKOUT_DIR%\out\gyp directory
+ * Double-click on dm.sln to start Visual Studio and load the project
+ * When Visual Studio starts, you may see an error dialog stating that "One or more projects in the solution were not loaded correctly"... but there's probably nothing to worry about.
+ * In the "Solution Explorer" window, right-click on the "dm" project and select "Set as StartUp Project".
+ * In the "Debug" menu, click on "Start Debugging" (or just press F5). If you get a dialog saying that the project is out of date, click on "Yes" to rebuild it.
+ * Once the build is complete, you should see console output from the tests in the "Output" window at lower right.
+
+Build and run SampleApp in Visual Studio
+----------------------------------------
+
+ * Generate the Visual Studio project files by running gyp_skia as described above
+ * Open a File Explorer window pointing at the %SKIA_INSTALLDIR%\trunk\out\gyp directory
+ * Double-click on SampleApp.sln
+ * When Visual Studio starts, you may see an error dialog stating that "One or more projects in the solution were not loaded correctly"... but there's probably nothing to worry about.
+ * In the "Debug" menu, click on "Start Debugging" (or just press F5). If you get a dialog saying that the project is out of date, click on "Yes" to rebuild it.
+ * Once the build is complete, you should see a window with various example graphics. To move through the sample app, use the following keypresses:
+ * right-arrow key: cycle through different test pages
+ * left-arrow key: cycle through rendering methods for each test page
+ * other keys are defined in SampleApp.cpp’s SampleWindow::onHandleKey() and SampleWindow::onHandleChar() methods
+
+Build and run nanobench (performance testbench) from the command line
+---------------------------------------------------------------------
+
+Since nanobench tests performance, it usually makes more sense to run it in Release mode.
+
+ ninja -C out\Release nanobench
+ out\Release\nanobench
--- /dev/null
+Building with Skia Tutorial
+===========================
+
+dsinclair@chromium.org
+
+
+This document describes the steps used to create an application that uses Skia. The assumptions are that you're using:
+
+ * [git](http://git-scm.com)
+ * [gclient](https://code.google.com/p/gclient/)
+ * [gyp](https://code.google.com/p/gyp/)
+ * [ninja](http://martine.github.io/ninja/)
+
+I'm going to describe up to the point where we can build a simple application that prints out an SkPaint.
+
+Overview
+--------
+
+ 1. Create remote repository.
+ 1. Configure and sync using gclient.
+ 1. Create DEPS file to pull in third party repositories.
+ 1. Setup gitignore for directories pulled in from DEPS.
+ 1. Configure GYP.
+ 1. Setup GYP auto-run when gclient sync is executed.
+
+gclient setup
+-------------
+The first step is to setup a remote git repo, take your pick of provider. In
+my case, the repo is called UsingSkia and lives on
+[bitbucket](https://bitbucket.org).
+
+With the remote repo created, we create a .gclient configuration file. The
+gclient config command will write the file for us:
+
+ $ gclient config --name=src https://bitbucket.org/dj2/usingskia.git
+
+This will create the following:
+
+ solutions = [
+ { "name" : "src",
+ "url" : "https://bitbucket.org/dj2/usingskia.git",
+ "deps_file" : "DEPS",
+ "managed" : True,
+ "custom_deps" : {
+ },
+ "safesync_url": "",
+ },
+ ]
+ cache_dir = None
+
+The name that we configured is the directory in which the repo will be checked
+out. This is done by running gclient sync. There is a bit of magic that
+gclient does around the url to determine if the repo is SVN or GIT. I've found
+the use of ssh:// and the .git on the end seem to work to get the right SCM
+type.
+
+ $ gclient sync
+
+This should execute a bunch of commands (and, in this case, may end with an
+error because the repo was empty. That seems to be fine.) When finished, you
+should have a src directory with your git repository checked out.
+
+DEPS
+----
+
+With the repo created we can go ahead and create our src/DEPS file. The DEPS
+file is used by gclient to checkout the dependent repositories of our
+application. In this case, the Skia repository.
+
+Create a src/DEPS file with the following:
+
+~~~~
+
+ vars = {
+ "skia_revision": "a6a8f00a3977e71dbce9da50a32c5e9a51c49285",
+ }
+
+ deps = {
+ "src/third_party/skia/":
+ "http://skia.googlecode.com/skia.git@" + Var("skia_revision"),
+ }
+
+~~~~
+
+There are two sections to the `DEPS` file at the moment, `vars` and `deps`.
+The `vars` sections defines variables we can use later in the file with the
+`Var()` accessor. In this case, we define our root directory, a shorter name
+for any googlecode repositories and a specific revision of Skia that we're
+going to use. I've pinned to a specific version to insulate the application
+from changes in the Skia tree. This lets us know that when someone checks out
+the repo they'll be using the same version of Skia that we've built and tested
+against.
+
+The `deps` section defines our dependencies. Currently we have one dependency
+which we're going to checkout into the `src/third_party/skia` directory.
+
+Once the deps file is created, commit and push it to the remote repository.
+Once done, we can use gclient to checkout our dependencies.
+
+ $ gclient sync
+
+This should output a whole bunch of lines about files that are being added to
+your project. This may also be a good time to create a `.gitignore` file. You
+don't want to check the `third_party/skia directory` into your repository as
+it's being managed by gclient.
+
+Now, we've run into a problem. Skia itself has a `DEPS` file which defines the
+`third_party` libraries it needs to build. None of those dependencies are being
+checked out so Skia will fail to build.
+
+The way I found around that is to add a second solution to the `.gclient`
+file. This solution tells gclient about Skia and will pull in the needed
+dependencies. I edited my `.gclient` file (created by the `gclient config`
+command above) to look as follows:
+
+ solutions = [
+ { "name" : "src",
+ "url" : "https://bitbucket.org/dj2/usingskia.git",
+ "deps_file" : "DEPS",
+ "managed" : True,
+ "custom_deps" : {
+ },
+ "safesync_url": "",
+ },
+ { "name" : "src/third_party/skia",
+ "url" : "http://skia.googlecode.com/skia.git@a6a8f00a3977e71dbce9da50a32c5e9a51c49285",
+ "deps_file" : "DEPS",
+ "managed" : True,
+ "custom_deps" : {
+ },
+ "safesync_url": "",
+ },
+ ]
+ cache_dir = None
+
+This is a little annoying at the moment since I've duplicated the repository
+revision number in the `.gclient` file. I'm hoping to find a way to do this
+through the `DEPS` file, but until then, this seems to work.
+
+With that done, re-run `gclient sync` and you should see a whole lot more
+repositories being checked out. The
+`src/third_party/skia/third_party/externals` directory should now be
+populated.
+
+GYP
+---
+
+The final piece of infrastructure we need to set up is GYP. GYP is a build
+system generator, in this project we're going to have it build ninja
+configuration files.
+
+First, we need to add GYP to our project. We'll do that by adding a new entry
+to the deps section of the `DEPS` file.
+
+ "src/tools/gyp":
+ (Var("googlecode_url") % "gyp") + "/trunk@1700",
+
+As you can see, I'm going to put the library into `src/tools/gyp` and checkout
+revision 1700 (note, the revision used here, 1700, was the head revision at
+the time the `DEPS` file was written. You're probably safe to use the
+tip-of-tree revision in your `DEPS` file). A quick `gclient sync` and we
+should have everything checked out.
+
+In order to run GYP we'll create a wrapper script. I've called this
+`src/build/gyp_using_skia`.
+
+~~~~
+#!/usr/bin/python
+import os
+import sys
+
+script_dir = os.path.dirname(__file__)
+using_skia_src = os.path.abspath(os.path.join(script_dir, os.pardir))
+
+sys.path.insert(0, os.path.join(using_skia_src, 'tools', 'gyp', 'pylib'))
+import gyp
+
+if __name__ == '__main__':
+ args = sys.argv[1:]
+
+ if not os.environ.get('GYP_GENERATORS'):
+ os.environ['GYP_GENERATORS'] = 'ninja'
+
+ args.append('--check')
+ args.append('-I%s/third_party/skia/gyp/common.gypi' % using_skia_src)
+
+ args.append(os.path.join(script_dir, '..', 'using_skia.gyp'))
+
+ print 'Updating projects from gyp files...'
+ sys.stdout.flush()
+
+ sys.exit(gyp.main(args))
+~~~~
+
+Most of this is just setup code. The two interesting bits are:
+
+ 1. `args.append('-I%s/third_party/skia/gyp/common.gypi' % using_skia_src)`
+ 1. `args.append(os.path.join(script_dir, '..', 'using_skia.gyp'))`
+
+In the case of 1, we're telling GYP to include (-I) the
+`src/third_party/skia/gyp/common.gypi` file which will define necessary
+variables for Skia to compile. In the case of 2, we're telling GYP that the
+main configuration file for our application is `src/using_skia.gyp`.
+
+The `src/using_skia.gyp` file is as follows:
+
+~~~~
+{
+ 'targets': [
+ {
+ 'configurations': {
+ 'Debug': { },
+ 'Release': { }
+ },
+ 'target_name': 'using_skia',
+ 'type': 'executable',
+ 'dependencies': [
+ 'third_party/skia/gyp/skia_lib.gyp:skia_lib'
+ ],
+ 'include_dirs': [
+ 'third_party/skia/include/config',
+ 'third_party/skia/include/core',
+ ],
+ 'sources': [
+ 'app/main.cpp'
+ ],
+ 'ldflags': [
+ '-lskia', '-stdlib=libc++', '-std=c++11'
+ ],
+ 'cflags': [
+ '-Werror', '-W', '-Wall', '-Wextra', '-Wno-unused-parameter', '-g', '-O0'
+ ]
+ }
+ ]
+}
+~~~~
+
+There is a lot going on in there, I'll touch on some of the highlights. The
+`configurations` section allows us to have different build flags for our `Debug`
+and `Release` build (in this case they're the same, but I wanted to define
+them.) The `target_name` defines the name of the build target which we'll
+provide to ninja. It will also be the name of the executable that we build.
+
+The dependencies section lists our build dependencies. These will be built
+before our sources are built. In this case, we depend on the `skia_lib` target
+inside `third_party/skia/gyp/skia_lib.gyp`.
+
+The include_dirs will be added to the include path when our files are built.
+We need to reference code in the config and core directories of Skia.
+
+`sources`, `ldflags` and `cflags` should be obvious.
+
+Our application is defined in `src/app/main.cpp` as:
+
+~~~~
+#include "SkPaint.h"
+#include "SkString.h"
+
+int main(int argc, char** argv) {
+ SkPaint paint;
+ paint.setColor(SK_ColorRED);
+
+ SkString* str = new SkString();
+ paint.toString(str);
+
+ fprintf(stdout, "%s\n", str->c_str());
+
+ return 0;
+}
+~~~~
+
+We're just printing out an SkPaint to show that everything is linking correctly.
+
+Now, we can run:
+
+ $ ./build/gyp_using_skia
+
+And, we get an error. Turns out, Skia is looking for a `find\_mac\_sdk.py` file in
+a relative tools directory which doesn't exist. Luckily, that's easy to fix
+with another entry in our DEPS file.
+
+ "src/tools/":
+ File((Var("googlecode_url") % "skia") + "/trunk/tools/find_mac_sdk.py@" +
+ Var("skia_revision")),
+
+Here we using the `File()` function of `gclient` to specify that we're checking
+out an individual file. Running `gclient sync` should pull the necessary file
+into `src/tools`.
+
+With that, running `build/gyp\_using\_skia` should complete successfully. You
+should now have an `out/` directory with a `Debug/` and `Release/` directory inside.
+These correspond to the configurations we specified in `using\_skia.gyp`.
+
+With all that out of the way, if you run:
+
+ $ ninja -C out/Debug using_skia
+
+The build should execute and you'll end up with an `out/Debug/using\_skia` which
+when executed, prints out our SkPaint entry.
+
+Autorun GYP
+-----------
+
+One last thing, having to run `build/gyp\_using\_skia` after each sync is a bit of
+a pain. We can fix that by adding a `hooks` section to our `DEPS` file. The `hooks`
+section lets you list a set of hooks to execute after `gclient` has finished the
+sync.
+
+ hooks = [
+ {
+ # A change to a .gyp, .gypi or to GYP itself should run the generator.
+ "name": "gyp",
+ "pattern": ".",
+ "action": ["python", "src/build/gyp_using_skia"]
+ }
+ ]
+
+Adding the above to the end of DEPS and running gclient sync should show the
+GYP files being updated at the end of the sync procedure.
+
--- /dev/null
+Creating a Skia "Hello World!"
+==============================
+
+This tutorial will guide you through the steps to create a Hello World Desktop
+application in Skia.
+
+Who this tutorial is for:
+-------------------------
+
+This will be useful to you if you want to create a window that can receive
+events and to which you can draw with Skia.
+
+Step 1: Check out and build Skia
+--------------------------------
+
+Follow the instructions for: Linux, Mac OS X or Windows. The framework that we
+will be using does not currently support other platforms.
+
+Once you have a working development environment, we can move on to the next step.
+
+Step 2: Build the included HelloSkia Example
+--------------------------------------------
+
+We will be using the "SkiaExamples" framework. You can find it in the
+experimental/SkiaExamples directory. There is an included HelloWorld example,
+and we will start by building it before we go ahead and create our own.
+
+### On Mac OS X
+
+Run `GYP_GENERATORS="ninja" ./gyp_skia`
+This will generate a ninja target, and `ninja -C out/Debug SkiaExamples` will create `SkiaExamples.app`
+
+### On Linux:
+Run `GYP_GENERATORS="ninja" ./gyp_skia`
+
+Build the SkiaExamples target:
+
+ ninja -C out/Release SkiaExamples
+
+The SkiaExamples binary should be in `out/Release/SkiaExamples`
+
+### On Windows
+
+Run `./gyp_skia`
+
+There should be a Visual Studio project `out/gyp/SkiaExamples.vcproj` with
+which you can build the SkiaExamples binary.
+
+### Run the SkiaExamples.
+
+You should see a window open displaying rotating text and some geometry.
+
+Step 3: Create your own Sample
+------------------------------
+
+Create a file `experimental/SkiaExamples/Tutorial.cpp` within the Skia tree. Copy the following code:
+
+~~~~
+
+#include "SkExample.h"
+#include "SkDevice.h"
+
+class HelloTutorial : public SkExample {
+ public:
+ HelloTutorial(SkExampleWindow* window)
+ : SkExample(window)
+ {
+ fName = "Tutorial"; // This is how Skia will find your example.
+
+ fWindow->setupBackend(SkExampleWindow::kGPU_DeviceType);
+ // Another option is the CPU backend: fWindow->setupBackend(kRaster_DeviceType);
+ }
+
+ protected:
+ virtual void draw(SkCanvas* canvas) SK_OVERRIDE {
+ // Clear background
+ canvas->drawColor(SK_ColorWHITE);
+
+ SkPaint paint;
+ // Draw a message with a nice black paint.
+ paint.setFlags(SkPaint::kAntiAlias_Flag);
+ paint.setColor(SK_ColorBLACK);
+ paint.setTextSize(SkIntToScalar(20));
+
+ static const char message[] = "Hello World!";
+
+ // Translate and draw the text:
+ canvas->save();
+ canvas->translate(SkIntToScalar(50), SkIntToScalar(100));
+ canvas->drawText(message, strlen(message), SkIntToScalar(0), SkIntToScalar(0), paint);
+ canvas->restore();
+
+ // If you ever want to do animation. Use the inval method to trigger a redraw.
+ this->fWindow->inval(NULL);
+ }
+};
+
+static SkExample* MyFactory(SkExampleWindow* window) {
+ return new HelloTutorial(window);
+}
+static SkExample::Registry registry(MyFactory);
+
+~~~~
+
+
+Step 4: Compile and run SkiaExamples with your Sample
+-----------------------------------------------------
+
+Here is what you have to do to compile your example. There will be
+functionality to make this easier, but for now, this is what you have to do:
+ * Open `gyp/experimental.gyp` and look for the `SkiaExamples` target.
+ * In the 'sources' section of the SkiaExampels target, add
+ `../experimental/SkiaExamples/Tutorial.cpp` to the list of sources.
+ * Repeat Step 2 to update our gyp targets and build our example.
+ * Run the SkiaExamples, specifying the name of our new example: `$> out/Release/SkiaExamples --match Tutorial`
+
+Step 5: How to iterate through multiple examples
+------------------------------------------------
+
+If you did not specify an example with the --match flag, or if your match
+string matches more than one example, you can use the *n* key to iterate
+through all of the examples registered.
+
--- /dev/null
+Samples and Tutorials
+=====================
--- /dev/null
+Specialized Builds
+==================
+
--- /dev/null
+Skia Lua Bindings
+=================
+
+**Warning: The following has only been tested on Linux, but it will likely
+work for any Unix.**
+
+Prerequisites
+-------------
+
+This assumes one already has Skia building normally. If not, refer to the
+quick start guides. In addition to that, you will need Lua 5.2 installed on
+your system in order to use the bindings.
+
+Building lua requires the readline development library. If missing this can be installed (on Ubuntu) by executing:
+
+ * `apt-cache search libreadline` to see the available libreadline libraries
+ * `sudo apt-get install libreadline6 libreadline6-dev` to actually install the libraries
+
+Build
+-----
+
+The build process starts the same way as described in the quick starts, but
+before using gyp or make, do this instead:
+
+ $ export GYP_DEFINES="skia_shared_lib=1"
+ $ make tools
+
+This tells Skia to build as a shared library, which enables a build of another shared library called 'skia.so' that exposes Skia bindings to Lua.
+
+Try It Out
+----------
+
+Once the build is complete, use the same terminal:
+
+ $ cd out/Debug/
+ $ lua
+
+ Lua 5.2.0 Copyright (C) 1994-2011 Lua.org, PUC-Rio
+ > require 'skia'
+ > paint = Sk.newPaint()
+ > paint:setColor{a=1, r=1, g=0, b=0}
+ > doc = Sk.newDocumentPDF('test.pdf')
+ > canvas = doc:beginPage(72*8.5, 72*11)
+ > canvas:drawText('Hello Lua', 300, 300, paint)
+ > doc:close()
+
+The key part to loading the bindings is `require 'skia'` which tells lua to look
+for 'skia.so' in the current directory (among many others) and provides the
+bindings. 'skia.so' in turn will load 'libskia.so' from the current directory or
+in our case the lib.target directory. 'libskia.so' is what contains the native
+skia code. The script shown above uses skia to draw Hello Lua in red text onto
+a pdf that will be outputted into the current folder as 'test.pdf'. Go ahead and
+open 'test.pdf' to confirm that everything is working.
+
--- /dev/null
+Using ANGLE on Windows
+======================
+
+Introduction
+------------
+
+ANGLE converts OpenGL ES 2.0 calls to DirectX 9 calls. These instructions
+document how to use ANGLE instead of the native OpenGL backend on Windows.
+
+Details
+-------
+
+Angle is now downloaded as a part of Skia according to the `DEPS` file.
+
+Add `skia_angle=1` to your `GYP_DEFINES` environment variable.
+
+Run:
+
+ python gyp_skia
+
+Remember
+--------
+
+In SampleApp you will need to use the 'D' key to get to the ANGLE backend unless you enable the `DEFAULT_TO_ANGLE` #define in `SampleApp.cpp`.
+
+ * Use “--angle” to enable ANGLE in gm.
+
+ * Use “--config ANGLE” to use ANGLE in bench.
+
+ * Use "--config angle" to use ANGLE in bench_pictures and render_pictures.
+
+ANGLE will automatically be compiled into the GLInterfaceValidation test.
projects / platform / upstream / libSkiaSharp.git / commitdiff