What 3D capabilities will Longhorn/Avalon provide? | TheChannel9Team

Karthik

Quite interesting, but I do have a few questions.

- What about some of the features in DX, that are used in UI Design too (DirectShow for one) - would Avalon programmers need to rewrite the wheel, and how will the existing UI code-base fit in?

- Would it be possible to combine DX/OpenGL with Avalon - a graphics product that I work on uses x86 asm to make mathematical calculations that need to be fast and higher level APIs for the not-so-important stuff. So, can I use Avalon for the UI and "bare metal" DX for other parts, or how does this work?

- Content delivery + graphics capabilities brings multimedia to mind (and DRM). Is that a targeted area?

- Are you looking at getting rid of Winforms in upcoming releases? "Writing Winforms is not the wrong thing" - but is it the right thing?

- From what I gather, all the capabilities of Avalon seem to be directed more towards cool UI stuff - does this involve things like Info-Viz (which are not quite graphics intensive as games are, but do need significant amounts of processing power). Is this a targeted area?

JBeda
Avatar stolen directly from messenger

Great questions Karthik!

Karthik wrote:

- What about some of the features in DX, that are used in UI Design too (DirectShow for one) - would Avalon programmers need to rewrite the wheel, and how will the existing UI code-base fit in?

Are you referring to people building on top of Avalon, or the people writing Avalon (meaning me and my coworkers? I'm guessing you mean people building on top of Avalon.

Out commitment to app compat means that any application written today will continue to run for the forseeable future. If you want to start mixing in some avalon technology with some of your currently running stuff, there are some restrictions. Mostly, wrt DX and things like DShow, you can always put those in their own child window and then composite that child window into an Avalon application. For things like video specifically, we are working to provide a more integrated API for what we think most users will want to do. Our team is called the "Media Integration Team" because we want to give developers a good and consistent experience when working with all types of media: vector graphics, video, text, imaging, etc.

So, your old stuff will continue to work. You can move stuff over to Avalon on a child window by child window basis if you like. And for new development we are working on providing a more integrated consistent API than MS has ever released before.

Karthik wrote:

- Would it be possible to combine DX/OpenGL with Avalon - a graphics product that I work on uses x86 asm to make mathematical calculations that need to be fast and higher level APIs for the not-so-important stuff. So, can I use Avalon for the UI and "bare metal" DX for other parts, or how does this work?

This is a scenario that we imagine will be pretty compelling. There should be no problem with you writing all of the UI for a program in Avalon but having the "canvas" of that program be written in DX or OpenGL. Just create a child window and render DX in to that. We'll take care of making sure that the DX gets drawn to the screen in a consistent way. In fact, DX child windows will integrate better in Avalon than the ever did in pervious versions of windows. I have a friend from high school who works for a game company writing internal tools. He asked me some of the same questions. I responded in my blog here.

Karthik wrote:

- Content delivery + graphics capabilities brings multimedia to mind (and DRM). Is that a targeted area?

I'm not super in the loop with what is going on there. I'll mention to Scoble that perhaps finding someone to interview about DRM would be a good thing.

Karthik wrote:

- Are you looking at getting rid of Winforms in upcoming releases? "Writing Winforms is not the wrong thing" - but is it the right thing?

I posted to that in another thread here. I mean that you shouldn't let the fact that Avalon is coming stop you from using a great (and evolving!) technology that exists and is shipping today. Check out this thread here.

Karthik wrote:

- From what I gather, all the capabilities of Avalon seem to be directed more towards cool UI stuff - does this involve things like Info-Viz (which are not quite graphics intensive as games are, but do need significant amounts of processing power). Is this a targeted area?

By Info-Viz, I'm guessing you mean "Info Visualization." I'm thinking that is definately one of the ways that people will start using Avalon do something more than just "Clickable Flying Stuff". It is also one of the places where I think that 3D in Avalon will shine. Do you have some specific examples that you'd like me to comment on?

Thanks for the questions!

Karthik

Thanks, Joe! That just about answered all my questions - but I do have a couple of clarifications to make.

JBeda wrote:

Are you referring to people building on top of Avalon, or the people writing Avalon (meaning me and my coworkers? I'm guessing you mean people building on top of Avalon.

I meant people who would be building on top of Avalon. The latter part of your answer did clear up my doubts, thanks!

JBeda wrote:

Mostly, wrt DX and things like DShow, you can always put those in their own child window and then composite that child window into an Avalon application.
....
....
So, your old stuff will continue to work. You can move stuff over to Avalon on a child window by child window basis if you like. And for new development we are working on providing a more integrated consistent API than MS has ever released before.

Ah. I get it. But I would like to see how this would work, since I've noticed a lot of problems with OpenGL/DX/GDI integration (a classic problem is a clash between InvalidateRect and certain OpenGL APIs). It would be awesome if you guys could provide some kind of preferential API (what goes where for what child window and what is preferred for which child window, etc) - just a suggestion (am I making sense?).

JBeda wrote:

We'll take care of making sure that the DX gets drawn to the screen in a consistent way. In fact, DX child windows will integrate better in Avalon than the ever did in pervious versions of windows.

Coolness. One question, though - I'll quote from your Blog here.

JBeda wrote:

To affect any change, it was always necessary to create the builder, make the change, and set the old value in.

Just out of curiosity, would this not increase the overhead of the implementation?

JBeda wrote:

For simple 3D stuff (load up a model and spin it around like a 3D icon) we will have our own 3D API that doesn't pretent to offer all of the flexibility of D3D.

So where does one draw the line between Avalon and D3d? Smiley

JBeda wrote:

I posted to that in another thread here. I mean that you shouldn't let the fact that Avalon is coming stop you from using a great (and evolving!) technology that exists and is shipping today. Check out this thread here.

That was quite cool, thank you. I personally think you convinced me to stick to WinForms for quite a while Smiley

JBeda wrote:

By Info-Viz, I'm guessing you mean "Info Visualization." I'm thinking that is definately one of the ways that people will start using Avalon do something more than just "Clickable Flying Stuff". It is also one of the places where I think that 3D in Avalon will shine. Do you have some specific examples that you'd like me to comment on?

Yup. I was referring to this kind of work - Information Visualization of large amounts of data and the like. I guess my question is, would you recommend using Avalon for stuff where the viz. changes ever so often but is also heavily content driven? I imagine that as long as its not heavily graphics intensive (say high poly count and stuff), you can stick to Avalon. The moment you cross that line, you fall back to something like D3D. Am I right?

JBeda wrote:

Thanks for the questions!

Thank you for the great answers!

JBeda
Avatar stolen directly from messenger

Let me break this down and answer your remaining questions.

DX/OGL/GDI/Avalon interop
We will support hosting hwnds inside of Avalon content. For the output side of things these hwnds will be composited with the rest of the Avalon application just like a bitmap. You can rotate it, alpha blend it, draw on top of it, etc. You are probably best off restricting yourself to only using one "drawing" API per hwnds. We won't let you draw GDI into an Avalon window or let you host Avalon in a window that is in GDI mode. Wrt DX and OGL, I'm not sure how hard the limits will be, but best practice will be to stick with one drawing model per window. I hope this answers your question.

Builders
For everyone else out there, I think that Karthik is referring to this blog post. Early in our implementation we had a pattern called Builders. Before the PDC we switched over to something we call "Changeables." These are still being refined a little bit, but we think that meet our needs better than Builders did. Builders are no longer used anyplace.

When to use Avalon vs. D3D
We are still implementing the 3D support in Avalon, so I don't think we have any hard guidelines here. If you are willing to deal with issues of different drivers supporting different features, not working well over TS/Remote Desktop or on multimon system, you can go with D3D. For that extra work, you can squeeze every last bit of performance out of the system. If, instead, you want to stay with something that works well with the rest of the Avalon API and will provide a limited but well supported set of functionality, then Avalon 3D is a good choice.

Generally, though, we think that Avalon 3D will be a great way for the average developer to mix in a little 3D in an application -- whether that be for some sort of data visualization (for instance, a 3D bar chart) or for cool factor.

As the API develops and we see where the limits are, I'll be able to give some more advice here.

Karthik

Great answers, you clarified all my questions. Thanks a lot!

Karthik

And oh, any chance we could have a peek at sample code/APIs/screenshots - of Avalon, and Aero Wink

scobleizer
I'm the video guy

Aero is so secret that Kam wouldn't let me take pictures of it when I was in his office. Quite a bit of Avalon has been shared publicly, though (the 3D stuff is the only stuff that hasn't).

http://msdn.microsoft.com/longhorn is the place to go. There's lots of demos and other things up there.

JBeda
Avatar stolen directly from messenger

scobleizer wrote:

Quite a bit of Avalon has been shared publicly, though (the 3D stuff is the only stuff that hasn't). http://msdn.microsoft.com/longhorn is the place to go. There's lots of demos and other things up there.

I think we are giving a new build out soon. When that happens, I'll blog about it and give some examples of using the 3D API.

DouglasH
Just Causual

Joe,

Just expose the capabilities to use HLSL:)

I know from last years winhec (or around that time) that cleartype is suppose to be using shader technology in tier 2. It would be nice to have the api expose the capabilites to use shaders, while not mandating them.

Douglas