Disqus - Friends of noahrichards

Re: - Miguel de Icaza

migueldeicaza — Sat, 14 Nov 2009 11:41:14 -0000

Moonlight's engine (animation, graphics, video, audio) can be used either with a browser plugin, where a security sandbox is in effect or as a library that can be consumed by C/C++/C# applications.

That being said, perhaps initially the video editor needs to run entirely on the browser to reach more users (Mac and Windows users do not have Moonlight at this point).

Silvelright and Moonlight both can request access to the file system in a secure way, this could be used temporarily for this purpose, or both could just do video editing over the web, or they could contact a local shell application that delivers the videos (tiny HTTP server used to serve files) depending on how we want to handle the adoption piece we can pick one or the other.

What I envision is that the result of encoding the video is actually a XAML file that lists all the sources and the times at which each video start playing, including transitions (using alpha channel changes, or in the future pixel shader effects) to produce the final video.

The encoding from this to an actual set of files would have to be handled by Moonlight as we can make Moonlight run with an artificial clock (for example if you want to generate 60 fps, regardless of whether your computer can do 60 fps at the desired resolution).

The output would be a list of frames, which can then be encoded by any third party encoder.

Re: - Miguel de Icaza

migueldeicaza — Sat, 14 Nov 2009 11:41:14 -0000

Re: - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 19:45:33 -0000

I am just thinking that we need to look at applications that do not exist, are not complete or still require a lot of work ahead of them.

Banshee seems pretty mature.

Re: The future of Moonlight - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 15:21:11 -0000

Hello,

Yes, this is already possible and available *today*.Just check out moon/examples for code that is actually compiled against the mscorlib 2.0 family of libraries.

Re: - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 15:07:33 -0000

I cant wait to see this!

Re: - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 15:07:08 -0000

I do not know who will pay for it.

I am wondering if we could get enough companies/individuals interested in funding this activity?

Re: - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 15:06:33 -0000

I agree 100%.

This has been in the back of my mind since we started with Moonlight. I might have even brought this up publicly.

There are a couple of ways of doing this. I would personally like to see Microsoft open source the OOXML SDK as that code would not only take care of loading/saving files in OOXML format, it would also provide a foundation on which to build the actual editing/rendering capabilities. The office replacement could be built on top of the object model exposed.

Microsoft today gives it away for free, but without access to the source code, or the rights to make changes, so it can not be used for Silverlight apps. I think we need to keep asking Microsoft to opensource that library.

Re: The future of Moonlight - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 15:03:20 -0000

Running NetFlix is not the problem, supporting the DRM system is.

Microsoft licenses Play Ready for use on certain locked-down systems (like set top boxes, cell phones and other locked devices) but does not make it available in standard desktops, so this is a major challenge.

Re: - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 15:02:06 -0000

Max,

This is very intriguing! I want to start working on the platform abstraction now that trunk has been opened to make sure that we can bring the Moonlight engine to multiple platforms, exactly for the purpose stated in your comment.

I am also looking forward to what Microsoft will have to say about Silverlight 4; Perhaps there is full alignment, perhaps not. Only time will tell.

Re: - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 13:18:19 -0000

Agreed.

On a different note, I believe that we need a XAML editor (both Microsoft and us) that is cross platform. Currently Blend is a windows-only technology and I bet Microsoft is going to have a hard time convincing Mac-loving designers to use Windows to create content for the web.

So a Silverlight-based in-browser XAML designer seems to me like a choice that would benefit both Linux and Mac users.

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

migueldeicaza — Thu, 12 Nov 2009 10:38:27 -0000

With the correction, it should:

# alleviate - relieve: provide physical relief, as from pain; "This pill will relieve your headaches"
# alleviate - facilitate: make easier; "you could facilitate the process by sharing your knowledge"
wordnetweb.princeton.edu/perl/webwn

# alleviation - relief: the feeling that comes when something burdensome is removed or reduced; "as he heard the news he was suddenly flooded with relief"
wordnetweb.princeton.edu/perl/webwn

# alleviated - (of pain or sorrow) made easier to bear
wordnetweb.princeton.edu/perl/webwn

# alleviation - easing: the act of reducing something unpleasant (as pain or annoyance); "he asked the nurse for relief from the constant pain"
wordnetweb.princeton.edu/perl/webwn

# alleviate - To make less severe, as a pain or difficulty
en.wiktionary.org/wiki/alleviate

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

migueldeicaza — Wed, 11 Nov 2009 17:52:59 -0000

Fixed.

Re: Mono Tools for Visual Studio - Miguel de Icaza

migueldeicaza — Wed, 11 Nov 2009 08:16:16 -0000

Yes; We are working on it.

Re: Mono Tools for Visual Studio - Miguel de Icaza

migueldeicaza — Tue, 10 Nov 2009 17:31:46 -0000

It currently only debugs XSP, not the module loaded with mod_mono;

We are looking at debugging mod_mono for version 1.2

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

migueldeicaza — Tue, 10 Nov 2009 16:18:34 -0000

Right, your post contains a gratuitous attack on Mono. You can go make those comments elsewhere.

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

migueldeicaza — Mon, 09 Nov 2009 16:15:10 -0000

We agree, we are like Mickey Mouse: Known and loved by billions worldwide

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

migueldeicaza — Mon, 09 Nov 2009 16:12:19 -0000

Thanks for the link, that is an interesting idea!

Mono's new compacting GC uses a similar setup: large objects are not allocated in the shared heap, they are tracked separately on the large object list (details are at www.mono-project.com/Compacting_GC)

Re: Aleviating Memory Fragmentation in Mono - Miguel de Icaza

migueldeicaza — Mon, 09 Nov 2009 14:39:03 -0000

Right, the access performance would degrade slightly, as we need to lookup the chunk, before we dereference the pointer, not a lot of work.

Re: - Miguel de Icaza

migueldeicaza — Sat, 07 Nov 2009 18:40:43 -0000

Unity has a license agreement with Novell that grants them a commercial license. Send me email, and I can put you in contact with the OEM licensing group that handles this.

Re: - Miguel de Icaza

migueldeicaza — Thu, 05 Nov 2009 11:47:11 -0000

Not necessarily; But you have to distribute your object files and any other files necessary for the user to be able to relink the application when he upgrades or patches Mono on his own.

If this is not suitable for you, you can buy a license from Novell for static linking that gives you the rights to the Mono runtime for commercial/non-LGPL use.

Re: Introducing Debugging for MonoTouch - Miguel de Icaza

migueldeicaza — Wed, 04 Nov 2009 19:41:08 -0000

MacOS X should already have a working debugger, we just need to package it.

But it should make it simpler to support debuggers in strange platforms. You still want to have the hard debugger around, so a port would not hurt anyone.

Re: 10 years of Ximian - Miguel de Icaza

migueldeicaza — Mon, 19 Oct 2009 16:08:02 -0000

The other day I found the business cards for "International Gnome Support" ;-)

Re: Event mapping in MonoTouch - Miguel de Icaza

migueldeicaza — Fri, 16 Oct 2009 09:39:10 -0000

I have never heard of this problem in .NET, can you be more specific?

But also keep in mind that there is an overloaded word in this post about delegates. The C# delegates and the Objective-C delegate pattern. Two different concepts that we blended together.

Re: Event mapping in MonoTouch - Miguel de Icaza

migueldeicaza — Thu, 15 Oct 2009 22:53:57 -0000

The system works a little bit like that, but we wanted to keep objects lightweight, so if you do not use the C# event, you do not pay the price in memory use.

To the programmer, it is transparent.

Re: Git# - First Public Release - Miguel de Icaza

migueldeicaza — Tue, 13 Oct 2009 15:39:34 -0000

Bringing IKVM to the iPhone or Silverlight is likely a major effort; So fewer dependencies using only the core of C# is a good idea.

That way C# is not at a disadvantage.

That being said, jGit or C# GIT would be further along if you contributed code to either effort.