Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Expert to Expert: Inside Bling - A C#-based library to simplify WPF programming

52 minutes, 12 seconds


Right click “Save as…”

Bling is a C#-based library for easily programming images, animations, interactions, and visualizations on Microsoft's WPF/.NET. Bling is oriented towards design technologists, i.e., designers who sometimes program, to aid in the rapid prototyping of rich UI design ideas. Students, artists, researchers, and hobbyists will also find Bling useful as a tool for quickly expressing ideas or visualizations. Bling's APIs and constructs are optimized for the fast programming of throw away code as opposed to the careful programming of production code.

Some features of Bling:

  • Declarative constraints that maintain dynamic relationships in the UI without the need for complex event handling. For example, button.Width = 100 - slider.Value causes button to shrink as the slider thumb is moved to the right, or grow as it is moved to the left. Constraints have many benefits: they allow rich custom layouts to be expressed with very little code, they are easy animate, and they support UIs with lots of dynamic behavior.
  • Simplified animation with one line of code. For example, button.Left.Animate.Duration(500).To = label.Right will cause button to move to the right of label in 500 milliseconds.
  • Pixel shader effects without the need to write HLSL code or boilerplate code! For example, canvas.CustomEffect = (input, uv) => new ColorBl(new Point3DBl(1,1,1) - input[uv].ScRGB, input[uv].ScA); defines and installs a pixel shader on a canvas that inverts the canvas's colors. Pixel shading in Bling takes advantage of your graphics card to create rich, pixel-level effects.
  • Support for multi-pass bitmap effects such as diffuse lighting.
  • An experimental UI physics engine for integrating physics into user interfaces! The physics supported by Bling is flexible, controllable, and easy to program.
  • Support for 2.5D lighting.
  • A rich library of geometry routines; e.g., finding where two lines intersect, the base of a triangle, the area of triangle, or a point on Bezier curve. These routines are compatible with all of Bling's features; e.g., they can be used in express constraints, pixel shaders, or physical constraints. Bling also provides a rich API for manipulating angles in both degrees and radians.
  • And many smaller things; e.g., a frame-based background animation manager and slide presentation system.
  • As a lightweight wrapper around WPF, Bling code is completely compatible with conventional WPF code written in C#, XAML, or other .NET languages.


    Sounds very interesting. Well, Erik and I wanted to find out more about Bling (Is it a library or a DSL? Is WPF programming really that hard? How is Bling designed and what makes it a simplified abstraction over a full featured platform technology like WPF?). It just so happened that Bling creator and software developer Sean McDirmid was in town recently (he works at Microsof's Advanced Technology Center located in Beijing, China). Tune in to see how the latest E2E unfolded (you must realize by now that we never really plan anything and E2Es just happen as you see them - it's just part of the game we play). Bling is an interesting idea with potential. Simplifying complexity is an important goal.


  • Tags:

    Follow the discussion

    • Oops, something didn't work.

      Getting subscription
      Subscribe to this conversation
    • Allan LindqvistaL_ Kinect ftw

      cool Smiley but im a little confused.. how does this relate to xaml? the argument is that setting up a binding is so verbose [and i agree with that for custom expressions, althoguh thats partially migitated by using a viewmodel] but setting up bindigs in xaml is not verbose, or atleast far less so than setting up a wpf binding in c#.. isnt that the whole point of xaml? to take the writing of ui in c# and make it less verbose?

      now we're writing ui in c# again? seems like a step back :/ for me it would make more sene if you used expressions in you xaml bindings: <Label Content={Binding Path=Name+Age}> or something. im not a wpf guru by any means but wouldnt it be possible to achive this by having a markup extension and perhaps pass it a string that represent the expression you wan tto bind to and then genereate a expression/function from that? maybe thats how bling works already Smiley [not done watching yet]


      the pixelshader stuff is really cool.. too bad we didnt get to see much of it though Smiley translating c# into hlsl would have really interesing possebilities for GPGPU applications from .net.. hoping for some some announcement in that space soon... Smiley ..and natal videos Wink

      good stuff Smiley

    • It would be good to see a piece where Sean's obvious enthusiam was encouraged to come across without being squashed at every turn by Eric wanting to show off.  Check the last frame.  If looks could kill, Eric would be a dead man.

    • CharlesCharles Welcome Change

      Erik wasn't showing off. This is Expert to Expert. Experts often encourage fellow experts to did deeper, explain their reasoning at every turn. I did not sense any bullying or grandstanding. Sorry you perceived that.I'll pass this along to Erik (well, he's probably already read this....). What about the content? Do you think Bling is useful? Does it really solve the poblems it's attempting to address?


    • CharlesCharles Welcome Change

      XAML isn't functional (meaning you can't handle events, compose algorithms, etc in XAML. It's design layout mark-up with support for data bindfing UI elements). Bling is for programming interactive experience, not just layout and databinding (which is somewhat more complicated than it needs to be today, generally). Have you played with Bling yet? What do you think? Also, Bling is really a prototyping tool and useful for those who don't understand the intracacies of WPF.


    • Bling looks great, I'm certainly going to play with it. I think that Erik was trying to get information from Sean on what the pain points in C# are and how MS can improve C#/VB to make even more impressive libraries/DSLs possible. I agree that it would be great to have a video with more in-depth explanations about the different parts of Bling.

      BTW is there a Scala version of Bling?

    • Allan LindqvistaL_ Kinect ftw

      yes i know that Smiley allthough you could argue that xaml does do composition quite well.. It is the back bone of wpf. you typicly do all your databinding and event wireups in xaml, not c#. hence my question, how does bling relate to xaml.  sean doesnt even mention xaml and all the databinding is done in c#. im just asking why that is.

      my point is that the argument that databinding is verbose and hard in xaml isnt fair, what is fair however is that databinding to a reactive expression is verbose and hard. but thats not the same thing Smiley even so, xaml is the way we write wpf ui and code behinds are something you typically want to avoid for testing purposes (in favor of a viewmodel for example). Also, a canvas that stacks its children using a reactive expression is more opaque than a stackpanel tag in xaml imo Smiley [yes i know thats just an example, but it still]

      as for your question, no i havent tried bling yet. i was hoping to get a quick awnser first, if xaml is not supported i fear it will be of limited use to me :/ also, time is not something i have in excess Sad


      not to forget [Data]Triggers, they do express application logic as well

    • *Disclaimer - I haven't watched the whole video yet.

      To be honest, I got annoyed in the first few minutes when Sean was getting interrupted and not able to finish his thoughts. I understand the idea of experts having a back-and-forth, but it can be frustrating at an observer when no one actually finishes fully articulating their point because someone is jumping in with the next question or thinking they are helping to clarify. That being said...

      I think Bling is very interesting, but I'm really struggling with the target audience. To me, I don't see this as a prototyping tool that's going to make me any more efficient. But maybe I'm not doing prototyping at the same advanced level. I'm a developer who is crossing over into design. I see tools like Blend and Sketchflow as the future of my prototyping universe. Even when I'm writing the actual UI, i want to spend as much time in visual tools like Blend as humanly possible. I do not find binding to be a very painful experience right now (at least not to the extent this video implies). So when I find myself immediately disagreeing with some of the base assumptions, it's hard to stick with the concept.

      However, it sounds like there is some really cool stuff in here. I like the idea of easy constraints, for instance. I'd like to do more with physics in my applications (although, again, this is an area where the demo of physics behaviors in Blend 3 was a lot more exciting for me), and I have definitely found that doing anything beyond the simplist geometry calculations in WPF is currently way harder than it should be. So maybe there is value here for me, I just need to know how it could fit into my workflow.

      Value transitions are something that I currently really struggle with, and I'm wondering if Bling might address it. I see that it makes an effort to make creating bindings easier, but my current gripe with bindings isn't creating them in the first place, but dealing with what VISUALLY happens when the value changes. Especially when developing NUI applications, you want everything to transition smoothly. A value should almost never just update, it usually needs to animate to it's next value. Making this happen is completely manual and often requires short circuting the traditional binding methods. Could Bling be setup to, for instance, make a slider animate to the new value whenever it changes? Or could you tell a list box to always apply a given animation to an item about to be removed? I constantly deal with needing to add items to lists and then deal with the container in some way after it's been generated, or stop my code-behind from removing an item from a bound itemsource until I've had a chance to run a 'closing' animation. To me, these are the real pain points with the current binding system.

    • CharlesCharles Welcome Change

      Thanks for your feedback!


    • Bling seems to be one attempt to make it easier to code against some powerful and liberating stuff that would otherwise be written off as 'too hard' by the majority ... and that can only be good for the future of UI.

      I heard Sean trying manfully to get that across, and Erik (sorry about the earlier mis-spelling) missing it completely in favour of some DSL vs API whimsey.

      The fact that *I* competely missed the 'Expert to Expert' format I can only put down to being a victim of my new medication Wink

    • stevo_stevo_ Human after all

      wpf data binding is painful? uh there's me thinking it was really good..

    • Bent Rasmussenexoteric stuck in a loop, for a while

      I suppose it depends on how comfortable you are with boilerplate code. Some people have a lower pain threshold. People with a low threshold use lazy evaluation!

      This is #1 on my to-do list for WPF projects.

      At times Erik's challenging of the presenter can break the flow a little but it does bring in some interesting splinter-topics - something which might be discussed in more detail later. And all in all the interview is quite well done and does bring forward what this thing is about, dispite the off-road trips.

      I'd like another Expert to Expert with Erik and someone like Don Box on "Oslo" (or James Clark, or one of the key developers on the team).

      Also an Expert to Expert with Erik and Stephen Wolfram (that would be interesting).

      The idea of having an abstraction embedded into an API is an interesting one. And the whole DSL hype, as Erik puts it, reminds me of Bertrand Meyer's statement in OOSC, that applications should be like theories (which sounds intuitively right; obviously more right that it should be like a bowl of spaghetti.)

      Also nice is the whole discussion about Scala and trying to emulate Scala and functional concepts in C# as well as the selective use of generics and union types.

      Sean ought to work on WPF 5.

    • stevo_stevo_ Human after all

      Perhaps you are just doing it wrong.. I dont find myself writing 'boilerplate' code for binding.

    • Vesuviusvesuvius Count Orlock

      I have started working full-time with WPF, and to be honest, it's not that difficult. Though I've not watched this video yet, I'm afraid I'd look at a project created with this either with contempt or frustration that I'm unable to understand what is going on. WPF is bare-bones but we are on a level playing field at the moment.

      I've just read the Adam Nathan book, presently am reading Petzold, once you understand your routed events and dependency objects then you're 80% of the way there.

      An observation I've made, after a month of working with WPF day-in-day-out is that it is quicker than windows forms, when you use your data templates in listview/datagrids, and I adore the commanding structure, but once you want to start incorporating animations, transitions and the more advanced stuff, then be prepared to wait a while. almost like owner drawing Win32 controls. There is no magic button at present.

      The most important thing about using WPF is knowing Visual Basic or C# adroitly. Everything else falls into place.


    • stevo_stevo_ Human after all

      Yea, I think the reason is kind of like one of those 'have your cake and eat it' things, similar to how the GC works, it does tons for you and actually manages to out do general hand rolled stuff.. or similar to how thread management works, manually creating threads all over the app being bad because at the point where you create them, doesn't have enough context about other threads running..


    • Bent Rasmussenexoteric stuck in a loop, for a while

      To me, the salient point is whether this program

      CheckBoxBl checkBox = new CheckBoxBl(canvas) {
        Height = slider.Height,
        LeftTop = slider.RightTop,
      slider.Width = canvas.Width - checkBox.Width;

      is expressible as briefly or more briefly with WPF anno 2009 or whether this form of expression sacrifices anything in comparison.

      Any discussion about hardness beyond this is entirely irrelevant. It is not about hardness it is about unnecessary work. Any shorter road that brings you safely to your goal must be considered more optimal in some sense. Occam's razor applies.

      If a different road is chosen it is most likely because of syntactic bias, habbit or because it takes you to a different place - perhaps a place where performance is better.

      To expand the analogy, it is not about overcomming a mountain vs a walking a straight road; it is about a long straight road vs a short straight road.

      It is about the shortest path, the path of least resistance and the most direct way from thought to solution.

      {0,1}* is a domain-specific language for the domain of everything. Everything else just falls into place (end of cheap shot from me, hehe)


    • AuxonRichard.Hein Read it: ​http://bitc​oin.​org/bitcoin.​pdf

      That's harsh ... I didn't get that impression at all.  I thought Sean started off a bit shy and Eric was helping a bit by filling in some gaps with some good questions and relating things to other stuff the audience is already familiar with.  Later on Sean gets more relaxed and seems more comfortable to me.   Sure Eric started drilling him on DSL versus API etc..., but that's good IMHO because these are the tough kinds of questions that I'm wondering about too.  It was a bit of side track, but I'll bet others in the audience were wondering the same thing.

      I would certainly enjoy a followup on this to see Bling in action, and then Sean can get more of a chance to fill in whatever areas he wants to cover that he didn't get to delve into in this interview.

    • CharlesCharles Welcome Change

      We'll have Sean on C9 again. Probably at the end of summer (since I will be travelling to Beijing then).


    • To clarify, I really enjoyed my interview with Erik. I have to admit my video skills aren't that great, so I think if it sounds a little rough, this was from my own inexperience vs. any probelm I had with the questioning. 

      As for the other comments:


      • XAML is not a full programming language, and completely lacks an expression language (hence the need for C#/VB code behind), while Bling is heavily based on getting the most out of expressions. We were able to hack some of Bling's features into XAML as markup extensions, but this was not very effective (too many hacks), so we dropped it in the most recent version of Bling. You can always use Bling in a project that also uses XAML, Bling is a lightweight wrapper around WPF that won't interfere with your code when you don't want to use it. That being said, if your WPF code is XAML-intensive, Bling might not be a good fit. 
      • Translating C# code into HLSL and compiling it dynamically wasn't my idea, it was originally done by Brahma (http://brahma.ananthonline.net/), where they really are working on GPGPU tasks. I want to build a version of Bling for DirectX 11, then we'll have easy access to compute shaders. 
      • No Scala version of Bling, but Ingo Maier @ the EPFL is working on something called ScalaFX, which has a similar lineage (I worked with Ingo when I was at the EPFL, Bling comes from my experience in FRP). 
      • If you use WPF the way it is promoted as being used (configuring mostly high-level widgets), you won't see the need for Bling at all. However, as soon as you want to do something that a high-level widget can accomodate (e.g., a custom data grid whose number of visible rows/columns is determined by available space, or a 3D pie), Bling is very useful. Using databinding to express custom layouts is much easier than say...writing a new panel or composing other panels in intricate ways to get the desired layout (and Bling makes expressing databinding less verbose). 
      • Physical bindings actually solve the "Value Transition" problem really gracefully. Basically, what we do is create a binding of a specified strength less than 1 (e.g., .01 means, satisfy the constraint 1% on each time step). When its not changing, it will basically stay the same, but when the target value changes, it will move relatively smoothly to the new value (for a time step of 30 milliseconds and a strength of 1%, it will take 3 seconds). Using something called "inverse kinematics" we can create value transitions that are tweened via the physics engine but essentially wind up where we want them when we want them (imagine increasing the strength from 0 to 100% by the time where we want the transition to end). This is one of the reasons why physics is so exciting to the future of UI. 
      • WPF databinding is well designed and works fairly well, its just painful to write down complicated binding relationships (where verbosity = pain). This syntax problem is easy enough to fix though, without requiring any internal changes to WPF (Bling wraps around WPF). 
      Anyways, thanks for the comments!


    • Jilani ShaikhJilani Shaikh Jilani Shaikh

      This is rally nice VDO Thank U very much


      jilani shaikh

    • Hey Sean, thanks for the detailed response. I'm on board with the idea of using more physics-based layout for NUI design. I've worked with Surface quite a bit, and you're right, physics play a big part of building NUI apps. And what the Surface SDK has is not very flexible yet. I can see Bling being a great step towards a time when layout is thought of as a more fluid thing that just has constraints set around how you want it to behave.

      I think my next question would be what it would look like to integrate some physics-based Bling layout into a WPF application based on the MVVM pattern. And as long as you're (hopefully) reading this, do you have any opinion on the Behavior pattern introduced with Expression Blend 3? Some of the early examples of behaviors involve adding physical properties to visual objects by just dragging behaviors onto them in blend. This is very designer friendly because programmers can do the work of defining the physics and expose that functionality to the designers to be used at their discretion. Do you think it would be possilbe to combine Bling with these behaviors?

    • Yes and no. Blend 3 behaviors allow you to create a physical container and control high-level physical properties such as mass and gravity, and perhaps add springs and pivots between objects. This can be useful if you want some simple physical effects, but it doesn't allow you to express the kind of constraints or inverse kinematics needed to use physics in a real UI. Bling allows you to express these constraints as expressions in C#, which would be much more difficult to express in XAML (which lacks its own expression language) and therefore Blend.

      To be perfectly honest, you are going to need to know/leverage a fair amount of trigonemetry and even a little bit of calculus to express many of the useful custom physical constraints, so it might be beyond designer-friendly right now (even if you could write it down in Blend/XAML). This is just a fundamental limitation of any design tool: they can allow you to do simple things simply (as it should be!) but can't do much about the complicated things (e.g., complicated/dynamic animations, layouts, or physical relationships...). 

      Right now, Bling aims more at the Processing and Flash/ActionScript audience, who are designers that are more technical, prototypers, or devs/researchers just playing around. I'm not really familiar with MVVM but...it seems more like a strategy for long-lasting production code vs. UX prototypes (where you don't want to think too much about architecture/evolution). Most Bling programs start with a canvas and if data is involved (e.g., sample lab report data in a medical reporting prototyping), we just bring it in as an after thought.

    • The discussion on DSL's was interesting.  I am inclined to agree with Sean and consider Bling a DSL (or at least an embedded DSL).  So where do we draw the line?  Well when it comes to expression trees I think it is easy to make the distinction.  If an API examines the expression tree and does something beyond simply compiling the expression tree and running it as is then I consider it an embedded DSL.

      So with that in mind LINQ to Objects is not a DSL but LINQ to SQL is a DSL.  LINQ to SQL is taking a subset of C#/VB (expression trees and a subset of expression trees at that) and transforms that into another form that is a domain specific (produces SQL that is then run against a database and then maps the results of that query from that domain back into the domain of .NET objects). 

      Bling is exactly the same, it takes expression trees and transforms them into WPF MultiBindings or HLSL shaders etc (and in some cases obviously compiles and runs the expression tree as well).  So again we have transformed from one domain to another.

    • The meta-argument is an interesting distinction. Or more generally, we could state that if a library/application interpret/translates an input tree to create behavior, then the language of the input is a DSL.

      I would still think that LINQ was a DSL, since syntax was defined at that level, but it gets weird because additional semantics are defined by LINQ to SQL or LINQ to objects. Still, new syntax and semantics to me also indicates a DSL. 

    • Now if only C# allowed compile-time restrictions on what was allowable in certain expression trees (perhaps just some FxCop rules, since FxCop is like an extra compiler stage anyway) then with a well designed API and subsets of expression trees then C# would be a fairly useful DSL host.

    • The lack of compile-time isn't such a big problem: if their is an error in your tree construction, you're code will often blow-up early in application execution rather than some indeterminite time in the future. Essentially, we now have 3 stages of error checking to consider: compile-time, generation-time (essentially on application startup), and actual run-time. Generation-time errors are fairly easy to debug, as long as we focus on crafting good strings in the thrown exceptions (admittedly I haven't done a great job here yet). Compile-time checking would be limited by the information available, of course, and I'm not confident that it could be powerful enough to reduce flexibility necessary in allowing for convenient tree constructions. 

      It almost makes sense to blow off compile-time checking completely and rely on generation-time checking. Combined with the fact that performance isn't much of an issue during code generation (as long as the generated code runs fast!), the lightweight DSL approach used in Bling would be very well suited to a dynamic language such as IronPython or IronRuby.  Still, C# seems good enough, and the added static type checking is great for things like good Intellisense.

      On a related issue, debugging run-time errors is currently difficult because their is no current way to easily debug compiled trees in Linq/DLR. Hopefully, eventually we could match generated code with C# code used to create the generate code, but its a huge meta problem (basically, we need to somehow propagate source locations...) and the eventual solution probably involves writing a parser.

    • Something I definitely will be taking a closer look at. I've only read about flapjax but some of Bling does remind of it. 

    • William Staceystaceyw Before C# there was darkness...

      Very cool Sean.  I have wanted a way to animate via c# in such a way as I have not really got using the timeline yet and it seems harder in some ways.  Same with binding.  This seems like in general, this "method" seems like it can be bigger for .Net then just animations and binding.  Seem like a way to in general reduce all unneeded complexity in other domains too.  Really cool concept.  DSL like in the same way RegEx takes a shorter syntax and builds code in the background and library like in the sense that you use real types and language syntax (not some external language).  Really cool.

      Just curious.  As an example, how would one move button from left to right while also sizing it larger from left to right?  Have two seperate things here that need to happen as ~same time. 

      As a side thought, it would seem like animating something like a stick figure object (i.e. walking, jumping, etc) could be made faily easy with bling doing all the physics and joint movements based on human contraints, etc.  IIRC, Disney spent a lot of time doing this with their walking Dinosaur (Lucky).  The puppet master just tells it where to go, and the "bot" figures out exactly how based on various contraints.  Likewise, Bling could be used to surface these "smart" bot DSLs that you can just direct with simple commands and they do interesting things.   I would think MSRobotics could do some cool stuff with this.  We can then just say, go here, go there, turn around 180% and the "dsl" figures out the specifics.  Thanks much.

    • Rather than use a slider value, you could create your own new dependency property to sync the other properties (via data binding). Bling doesn't use storyboards, rather, most of the time we just animate things at the same time, or when possible, create relationships via databinding that are then influenced by an animation. First, you can just animate two properties at the same time, and they will just animate together (coincidentally but reliably); e.g.,

      button.Right.Animate.To = canvas.Width; // animate button to end of containing canvas.
      button.RenderTransform.ScaleXY.Animate.To = 2d; // animate button so that it is twice as large when reaching the end.

      Alternatively, you can relate scaling to the right position of the button:

      button.Right.Animate.To = canvas.Width; // animate button to end of containing canvas. 
      button.RenderTransform.ScaleXY = 1d + (button.Right / canvas.Width); 

      If you want to synchronize the properties so that they move in sync, you can relate them to a nuetrual property (say a slider value):

      button.Right = 0d + slider.Value * canvas.Width; // animate button to end of containing canvas. 
      button.RenderTransform.ScaleXY = 1d + slider.Value;

      slider.Value.Animate.To = 1d; 

      Actually, timeline animation is extremely limited and I'm 90% positive that the future of UI animation is through some form of physics. For a stick figure, for example, you can set a bunch of constraints on motion (e.g., joints) a long with goals..and you have plausible movement via inverse kinematics. Bling has evolving support for UI physics with plenty of small demos, you can check out the distribution on the codeplex page for more details. 

    • I've released a new version of Bling that supports more graphics in WPF and has initial support for DirectX 10. Check out the announcement on my blog.

    Remove this comment

    Remove this thread


    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.