Moonlight

At this time, Moonlight trunk (this release) requires you to use trunk to get the required dependency (e.g. latest Mono.Cecil) and compilers (e.g. the new 'mcs' compiler). To build mono, do like this: To build Moonlight, you'll also need to get the source code for mono and mono-basic repositories from a specific revision from trunk. To build pixel shader support, you need to get a specific revision of the mesa repository. The revision the codecs currently are at is: 15e2b1b2 (only applicable to buildbots and developers on the Moonlight team). For SVN users, the revision is: 10364 This will configure your Mono source tree with the minimum options required to build it for Moonlight. At the moment, these are: If you want to use SGen with Moonlight, you'll need use the following option when running autogen.sh: Warning: Moonlight+Sgen has not been fully tested yet, and is likely unstable. Enable this at your own risk This is recommended if you have built Mono before and you would like Moonlight to use your existing Mono source tree. This is for advanced users only - make sure you know what you're doing. In this mode, Moonlight will not touch your existing Mono configuration, it will build the parts it needs. Since it doesn't do a full build of mono+mcs, it's faster than a normal mono+mcs build. Warning: Moonlight+SGen has not been fully tested yet, and is likely unstable. Enable this at your own risk On this mode, moon will not configure or build mono, you have to do it yourself. To activate this mode, configure moon with --with-manual-mono=yes This will install it into your ~/.mozilla/plugins which will let both Firefox and Chrome pick it. A custom profiler is available which allows you to track which objects are being kept alive by strong GCHandles and also see the stacktrace for every gchandle that was not freed. On application shutdown, right before the appdomain is freed, a GCHandle 'leak' report will be printed. This will show all the objects being retained in memory because they have a strong gchandle attached to them. If you want to see where the gchandles were allocated you just have to export the following variable. This example will print the stacktraces of all the unfreed strong gchandles for the Uri type: If multiple strong handles are targetting the same CLR object, these will be grouped together. This makes it easy to see if 10,000 handles are targetting the same object or if its 10,000 different objects. There are a couple of runtime-parameters that affect Moonlight behavior and turn on/off certain features. Those options are specified through the MOONLIGHT OVERRIDES env variable. The more interesting ones are: Use some extra memory for caching shapes. Increases memory usage but helps with performance (off by default). The shape cache size is 6MB max. Controls which sets of codecs to use, the Microsoft ones or the ffmpeg ones. Also if --with-debug=yes option was provided to configure script, the MOONLIGHT DEBUG env variable controls which debug output is printed on the console. Valid values are: Moonlight currently contains two ASX parsers. The default parser is a custom parser that accounts for some of ASX's oddities such as quotes in attribute strings and non case sensitive element names (ie ). The older parser uses a true xml parser, so will not handle these oddities well, however it has been more heavily tested. To use the older expat based playlist parser set the env variable MOONLIGHT USE EXPAT ASXPARSER=1. There are two XAML parsers available in Moonlight. An unmanaged one that is used for Silverlight 1, 2 and 3 applications and a managed one that is used for silverlight 4 (and above) applications. The parser is determined at runtime after the app manifest is read. The unmanaged parser is always used to parse the app manifest. After that the correct parser is determined based on Deployment::RuntimeVersion. You can force moonlight to use the managed parser on all sites by setting the MOON