Over on Steven Engelhardt’s blog there’s a mandelbrot viewer written using silverlight 1.0 (meaning just xaml + javascript). In his post he listed a few problems he had, and one caught my eye:
- I can’t figure out how to do progressive (e.g. line-by-line) rendering to give the user feedback.
I figured this would be pretty easy with the help of setTimeout() and some more global state, so I hacked it together here. Instead of the line by line rendering I implemented a progressive jpg style interlaced rendering, with multiple passes of smaller and smaller pixels. As you can see in the demo, you can mouse over and click while it’s in the middle of rendering, and it’ll start the new render. No more waiting.
One thing he’s doing (that he notes is quite heavyweight) is using rectangles. To lessen the hit, he uses 1 rectangle for many contiguous pixels of the same color on the same line. I’d imagine using an InkPresenter and adding stylus points might be a less heavyweight approach (at least I think it will be in the case of moonlight.)
update: realized how to make mouse events faster - specify IsHitTestVisible=”false” on all the rectangles. That way the event system doesn’t have to worry about generating enter/leave events for each scan line (and for many individual pixels on those scanlines). And speaking of scan lines, add an translucent red indicator line that shows the next line to be drawn. Add more precision (down to pixel_size == 1), and when we’re finished rendering, display how many rectangle children of the main canvas there are (for the first render there are over 13000. that’s a lot of children. moonlight seems to handle it ok too 
A little while ago I committed the first ugly pass at windowless support in moonlight. By ugly I just mean I cut corners wherever I could, just to get it working. The changes to support both windowed and windowless modes, with events coming in as either GdkEvents or Xlib events.. well, they’re a little gross but we’ll get them refactored and beautified soon enough.
On to the goods.
Silverlight 1.0 has no built-in text input support, so the conventional wisdom says “use windowless mode, and use an overlayed html form element to allow input.” Many sites use this, such as the weatherwidget:
The vista simulator (which is a pretty crazy body of code. *Tons* of javascript, and an architecture that leads me to believe it wasn’t originally intended for silverlight) uses windowless mode for another reason. It doesn’t hook up events handlers to any of the xaml elements. Instead, it adds JS event handlers to the <object> tag that surrounds the plugin. Since there are no event handlers in the plugin, we return FALSE to signal we didn’t handle the event, which bubbles up the dom hierarchy to the object.
You need svn HEAD of the moonlight code for this to work, and you also need to run it against a build of firefox3. Unfortunately, given our use of unfrozen apis for dealing with the dom element reflection into managed code, you’ll more than likely run up against undefined C++ symbols for pages that do that sort of thing. But there are a number of sites which don’t. So give it a try
I’ve been splitting time between a number of projects lately.
Most of my time has been spent on Moonlight, of course. Things are progressing pretty nicely. We have real QA, so regressions don’t go unnoticed. We have a bunch of new (for us) features, and a bunch more coming.
A smaller amount of weekend/after hours time has been spent brushing off the Trac stuff for SCSharp, and clearing the 2 year old backlog of porn spam and unfixed bugs. I’m surprised just how little it’s bitrotted. Check it out.
My newest project, which was mostly motivated by my frustration generating local class-status pages for the work I’d been doing filling out the WPF apis is “gui-compare”, found in mono-svn in mono-tools/gui-compare.
Basically it’s a gtk# frontend for class-status, but it allows some pretty nice features. You can compare any dll to any other (to see, say, the differences between the 1.1 and 2.0 mscorlibs in mono). It also knows how to read the masterinfo files that are generated by the mono-api-info stuff. Lastly (and perhaps most importantly), it downloads and caches the correct masterinfo files for you. No more groveling around for them on the mono site. Just fire up gui-compare and e.g. Compare -> API 1.1 -> System, and it downloads the files it needs and performs the comparison. I also stole a neat feature from MoMA, and gui-compare will show you which methods throw NotImplementedException. Here’s what my current build looks like:
Another nice thing about gui-compare for use in fleshing out apis: You look at gui-compare, find the stuff you want to implement, stub it out in your code (or implement it, whatever), install your assembly, and then hit Ctrl-r in gui-compare to re-run. Quite a bit easier than having another terminal open in mono/web/web waiting for me to type ‘make’. File watcher support coming soon to make even this step unnecessary.
Over-correcting can sometimes show how far we’ve swung into the land of hyperbole and over-engineering.
I started a few projects when I was staying with Graveley back in the first part of this year. One we started/worked on together, and a couple of others were solo. One of the solo projects was MNDB.
Originally this stood for “Mono Native Debugger” and it was mostly a crazy sounding manifesto full of condemnation of the lack of a functioning debugger for mono, and plans for how to rectify this. The manifesto still exists, but needs a little *ahem* polishing up before I make it public. The current state of the code itself, however, is worthy of a post. Also, I showed it to a few people at the moonlight summit this past week and they suggested I check it into svn, which I have. Check it out, tell me how crazy I am..
While “Mono Native Debugger” is still applicable, I think “Minimalist Debugger” is a little more appropriate. It’s just the barebones that I need to set breakpoints on method entry, use “next”, and (soon) print things out. A console log of a small test can be seen here (the grayed out portions are gdb output and debug spew). It doesn’t use cecil, it doesn’t support generics, it doesn’t do most things that the mono debugger does. But, as far as I can tell, what’s there works. And weighing in at 519 lines of gdb macros, it’s a hell of a lot easier to understand
On Lake Washington last night, miguel mentioned that a cool hack would be to add a “create from json” method for moonlight, to compliment “createFromXaml”. The idea being that xaml (like all xml) is overly verbose and isn’t a first class part of the language in JS (so you don’t get syntax errors on missed quotes, etc).
I woke up this morning and ran the idea through my head, and figured it would be an hour hack. I was wrong. It took 1.5 hours.
So, you start with something like:
var json = {
Canvas: {
name: "Toplevel Canvas", children: {
TextBlock: {
Text: "Hello World"
}
}
}
}
and it converts that to the following xaml:
<Canvas xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation” xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml” x:Name=”Toplevel Canvas”><TextBlock Text=”Hello World”/></Canvas>
Here it is: createFromJson.js
.
