ATI reveals Longhorn tidbits in presentation slides.

Society said:
winger.jpg


?

whiners
 
all those 3d interfaces would be cool if i had a 3d holo display, but if i'm still stuck with a monitor, what's the point? it's more of a detriment to have to navigate in a third dimension on a flat screen...
 
I'm pretty much sold on this. While everyone has compelling arguments, I think the reason I'm still sold on this is because I've dealt with programming GUI’s in C++ and the MFC classes. Also, the pitch I heard wasn't that it's all going to be in cool 3D, the pitch I was explained to first and sold on was that everything would be moving towards the 3D cards making the whole windows GUI Direct X and ditching out the old way of programming the GUI. The new Hardware 3D aspects of it are really just a bonus to working with something much easier and less confusing then Windows GUI.


I think mostly everyone here overlooked the programming aspect and completely went for the visual aspect of it. If it's one thing that Java showed everyone was that you don't need a bastardly complex GUI system like Window's to design an intuitive graphically pleasing GUI. Programming a GUI in VC++ was like pulling teeth out with rusted pliers, you could almost taste the mix of rust and blood in your mouth. On the other hand, Java showed that even the beginner in an introduction to Java course can create a nice looking GUI for their simple programs. One of the most powerful aspects of Java that the only way it could be the same for Windows would be to rip the whole Win GUI system out.

I see WFG 1.0 as not a break through in how you use windows, it's more of a break through in how you design and program GUI's. Open GL was the homebrew favorite as it's pretty easy to learn (once you get over trying to program a Windows "window" for it, bastardly difficult that most skip that part and just copy some generic window code.) Direct X on the other hand has evolved now where we have homebrew programmers making their 3D visuals (See Humus at beyond3D.) What if you extended that to the windows GUI? In fact since DirectX is so more accessible then the Windows GUI (by the butt loads) why not just adds the option to bypass Windows GUI completely? Hell why not rip it out, bury it, and pretend it never happened.
 
marsomega said:
I'm pretty much sold on this. While everyone has compelling arguments, I think the reason I'm still sold on this is because I've dealt with programming GUI’s in C++ and the MFC classes. Also, the pitch I heard wasn't that it's all going to be in cool 3D, the pitch I was explained to first and sold on was that everything would be moving towards the 3D cards making the whole windows GUI Direct X and ditching out the old way of programming the GUI. The new Hardware 3D aspects of it are really just a bonus to working with something much easier and less confusing then Windows GUI.

The new paradigm for programming in Windows (Avalon) has more to do with what you're talking about and less to do with Aero which is what the 3D layer is. Yes its great that GDI is going away, its great that MFC is going away, its great that the Win32 API is going away, however those things are being replaced with a set of .Net'able APIs atop which Aero sits. If you're interested in writing code, you really should hit a WinHEC or at least visit msdn.microsoft.com often because I think you're a little bit confused by the different layers of the OS UI.

"Avalon" is the code name for Microsoft's unified presentation subsystem for Windows. It consists of a display engine and a managed-code framework. "Avalon" unifies how Windows creates, displays, and manipulates documents, media, and user interfaces, which enables developers and designers to create visually-stunning, differentiated user experiences that improve customer connection.

* The "Avalon" Engine. The "Avalon" engine unifies the way developers and designers experience documents, media, and UI, providing a single runtime for browser-based experiences, forms-based applications, graphics, video, audio, and documents. "Avalon" is built on top of DirectX, which enables it to unleash the full power of the graphics hardware present in modern computers, and is engineered to exploit advances in hardware moving forward. For example, the "Avalon" vector-based rendering engine enables applications to scale to take advantage of high-dpi monitors without requiring extra work on the part of the developer or user. Similarly, when "Avalon" detects a video card that supports hardware acceleration, it takes advantage of it.

* The "Avalon" Framework. The "Avalon" framework delivers solutions for media, user interface design, and documents that go well beyond what developers have today. "Avalon" is designed for extensibility, enabling developers to create their own controls on top of the "Avalon" engine from scratch or by subclassing existing "Avalon" controls. Central to the "Avalon" framework are controls for shapes, documents, images, video, animation, 3D, and panels, in which to place controls and content. These primitives provide the building blocks for developing next generation user experiences.

* XAML. "Avalon" also introduces XAML, a markup language to declaratively represent user interface for Windows applications, improving the richness of the tools with which developers and designers can compose and repurpose UI. For Web developers, XAML provides a familiar UI description paradigm. XAML also enables the separation of UI design from the underlying code, enabling developers and designers to work more closely together.

For developers and designers, "Avalon" provides a unified UI platform, such that they can learn a single paradigm that provides limitless possibilities of UI experiences. For .NET developers, its framework will be familiar, and it will ultimately reduce the number of lines of code required to deliver optimal user experiences. For designers, "Avalon" offers a platform that eliminates boundaries between content, media, and applications. Most importantly, "Avalon" has been engineered so that developers and designers can work closely together synchronously to quickly deliver differentiated, connected experiences.


One of the most powerful aspects of Java that the only way it could be the same for Windows would be to rip the whole Win GUI system out.

Hopefully you're not referring to Swing. While Swing is an elegant API - intuitive it is not.

I see WFG 1.0 as not a break through in how you use windows, it's more of a break through in how you design and program GUI's.

Not quite. That's Avalon. You need to hit the MSDN site.

Open GL was the homebrew favorite as it's pretty easy to learn (once you get over trying to program a Windows "window" for it, bastardly difficult that most skip that part and just copy some generic window code.) Direct X on the other hand has evolved now where we have homebrew programmers making their 3D visuals (See Humus at beyond3D.)

Most people skip over it because it doesn't matter how you create. So long as you can get an HWND from a component - ANY component, you can render OpenGL in it. Creating Windows is one of the things you learn in the first 5 minutes of learing about the Win32 API or MFC :)

What if you extended that to the windows GUI? In fact since DirectX is so more accessible then the Windows GUI (by the butt loads) why not just adds the option to bypass Windows GUI completely? Hell why not rip it out, bury it, and pretend it never happened.

Not sure what you're trying to say here. There are far far far more machines in the world that run WIndows and can use the Win32 API or MFC than there are that can run DirectX.
 
There is nothing more painful than developing a UI for Windows (or anything, really) in Java. Ugh, I hate swing.
 
Nerevar said:
There is nothing more painful than developing a UI for Windows (or anything, really) in Java. Ugh, I hate swing.

Could be worse. You could be doing it in the Win32 API. That's a far worse evil - easily. MFC, meh. You could get by somewhat easier, though it was still easier to deal with Swing. Put it this way, I could build out a pretty complete application shell in Swing faster than anyone could in Win32 (and I'm prepared to take that challenge). Avalon, however, makes things much nicer.
 
Phoenix said:
The new paradigm for programming in Windows (Avalon) has more to do with what you're talking about and less to do with Aero which is what the 3D layer is. Yes its great that GDI is going away, its great that MFC is going away, its great that the Win32 API is going away, however those things are being replaced with a set of .Net'able APIs atop which Aero sits. If you're interested in writing code, you really should hit a WinHEC or at least visit msdn.microsoft.com often because I think you're a little bit confused by the different layers of the OS UI.

You have to work with me here. Like I said, I heard the pitch and the idea behind it. For me, getting rid of it all is a good thing. The structure and way of thinking behind it was just grinding for me as far as the things are now.


Phoenix said:
Hopefully you're not referring to Swing. While Swing is an elegant API - intuitive it is not.

Certain aspects of it were. I don't remember which one I worked more on, was it swing or javax. I agree that some aspects aren't and at some point I still don't understand them as a whole like displaying an image. (Encapsulating this, wrapping that or what not, just gave me the run around.) But in general I still stand by it, obviously someone who's familiar with it as well may not agree as certain downfalls of it may just weigh more to them or they applied more aspects of them in practice.



Phoenix said:
Most people skip over it because it doesn't matter how you create. So long as you can get an HWND from a component - ANY component, you can render OpenGL in it. Creating Windows is one of the things you learn in the first 5 minutes of learing about the Win32 API or MFC :)

Creating a window to display my 3D stuff with OpenGL was just painful. And trying to learn it was difficult, the way some of the things worked in the background etc.. Sure I learned what functions to call and what things need to be done, but to grasp of it was another story. To say it's the first thing people learn in 5 minutes is just useless to say from a constructive stand point. It may reflect on you and that’s all fine there are many plausible reasons why you learned in such a way. When you talk about people in general, sure, I can take something complicated tell them do this plus that and WOW, everyone knows this how to do this complicated what not in just 5 minutes. They may know the steps but do they really know what their doing?

Don't know, I not understanding at all what you meant with that comment. My first notion is you're just being jerk or elitist as they're everywhere apparently (computer science is full of them, just what I'm accustomed to when dealing with those jerks). But if your point is just that, and you're familiar with Java's approach why not compare and contrast instead?

Phoenix said:
Not sure what you're trying to say here. There are far far far more machines in the world that run WIndows and can use the Win32 API or MFC than there are that can run DirectX.


Well I really stated that comment with the home brewer in mind. Like OpenGL, look at nehe.gamedev.net. It’s basically the home of hundreds of kids at home on their PC dreaming of becoming a 3D programmer. I just transferred that interest over to DirectX as well. Now where are the home brewers dreaming of programming with the Windows GUI system? And most of them, not bold enough to say all of them, are slaughtered when they try to create the window to display their helloworld 3D OpenGL projects they created. That's if they even bother with it as now gamedev just gives you the window code.



I'm a computer engineer so you kind of have to work with me about certain things. My mind set right now is on the operating systems grad courses I'm doing. (Working on emulated R2000 MIPS processors emulating a dead OS we have bring back to life with C and C++. They lure you in saying it uses C++ so everything will be fine. But the damn processor doesn't support many of the damn libraries I was taught with. "Namespace, iostream, WTF(udge), they're not supported?")
 
marsomega said:
Creating a window to display my 3D stuff with OpenGL was just painful. And trying to learn it was difficult, the way some of the things worked in the background etc.. Sure I learned what functions to call and what things need to be done, but to grasp of it was another story.

I'll put it this way. Its the exact same approach you take when creating them with DirectX. All the APIs are looking for the window where they are to render. This is described in the HWND. Its the same in DirectX and OpenGL. There isn't any API difference there. You just need to create a window - ANY window and you can render right to it.

To say it's the first thing people learn in 5 minutes is just useless to say from a constructive stand point. It may reflect on you and that’s all fine there are many plausible reasons why you learned in such a way. When you talk about people in general, sure, I can take something complicated tell you do this plus that and WOW, everyone knows this how to do this complicated what not in just 5 minutes. They may know the steps but do they really know what their doing?

Can't comment on who/what was teaching you this - just stating why no one goes into detail about creating Win32 Windows in OpenGL. If you're doing Windows programming, the first thing you have to learn in the first chapter of any book is creating a Window. If you don't create a Window in the first chapter - you aren't going to get very far into WndProcs and similar.

Don't know, I not understanding at all what you meant with that comment. My first notion is you're just being jerk or elitist as they're everywhere apparently (computer science is full of them, just what I'm accustomed to when dealing with those jerks). But if your point is just that, and you're familiar with Java's approach why not compare and contrast instead?

Jerk/elitist I am not. Sometimes a duck really is a duck. Sometimes some generic window code really is just generic boilerplate window code. Its like trying to explain why 1+1=2. Sure I could go into set theory on why its that way (which would make elementary school suck - a lot) or you just accept that 1+1=2 and move on.

I'm going to give you some helpful advice here since you are a computer science student (I'm assuming). It is important to understand what something is doing, but realize that that understanding won't necessarily come until after you've used it. For example if I were to try and teach you neural networks and why they work - much pain and suffering would you have. However if you saw one work, what I told you would make sense.

Now onto the matter at hand. Avalon is Microsoft "XML on the brain" approach for describing (unfortunately) everything in the UI.

Code:
<Text> 
  <Text.TextEffects>
    <TextEffect CharacterIndex = "0" Count="1">
      <TextEffect.Transform>
        <TranslateTransform>
          <TranslateTransform.Y>
            <DoubleAnimation IsAdditive="True" Duration="10" 
                             RepeatBehavior="Forever" From="-20" To="20"/>
          </TranslateTransform.Y>
        </TranslateTransform>
      </TextEffect.Transform>
    </TextEffect>
  </Text.TextEffects>
  Hello world
</Text>

This will produce a nice animating Hello World. To achieve the same effect in Java would require Java2D, some Font classes, a Thread for animation, etc. So in many ways the Longhorn way is going to be a lot easier - if annoyingly full of goddamn XML tags all over the place.



Well I really stated that comment with the home brewer in mind. Like OpenGL, look at nehe.gamedev.net. It’s basically the home of hundreds of kids at home on their PC dreaming of becoming a 3D programmer. I just transferred that interest over to DirectX as well. Now where are the home brewers dreaming of programming with the Windows GUI system? And most of them, not bold enough to say all of them, are slaughtered when they try to create the window to display their helloworld 3D OpenGL projects they created. That's if they even bother with it as now gamedev just gives you the window code.

I'm not following you.


I'm a computer engineer so you kind of have to work with me about certain things. My mind set right now is on the operating systems grad courses I'm doing. (Working on emulated R2000 MIPS processors emulating a dead OS we have bring back to life with C and C++. They lure you in saying it uses C++ so everything will be fine. But the damn processor doesn't support many of the damn libraries I was taught with. "Namespace, iostream, WTF(udge), they're not supported?")

Embedded programming is fun (for me anyways). End up doing a lot of it in my mobile game development hobby. I will say that its cool that they even use C in the classes. Reminds me of a project I did years ago on a PS1 devkit that required me to do some RISC assembly code to move the matrices into place and then call the right interrupt to mult them together. Fun times.

Anyways, PM me to chat if you want to talk about DirectX,OpenGL, C embedded programming, RISC assembler. I almost miss those days and would be more than happy to help you out where I can.
 
Phoenix said:
I'll put it this way. Its the exact same approach you take when creating them with DirectX. All the APIs are looking for the window where they are to render. This is described in the HWND. Its the same in DirectX and OpenGL. There isn't any API difference there. You just need to create a window - ANY window and you can render right to it.

The OpenGL programming I did was to display my art or what not. The Window had to be created first and there was a much crap to it. This was circa 2001 though I doubt things have changed much back then but thats how it was presented.


You have to read my whole post through instead of making such assumptions. (Computer Science :lol .) Especially to keep track of many the resources you speak of (understandble if it were two computer science heads going at. Granted I still feel that I have enough to support getting a new GUI system for windows.). Except for Java though, I've been following much more closely however it's unrealted to GUI.

And yea, its about time we take this out of the thread. Tee hee
:)
 
Phoenix said:
<snip verbosity>

This will produce a nice animating Hello World. To achieve the same effect in Java would require Java2D, some Font classes, a Thread for animation, etc. So in many ways the Longhorn way is going to be a lot easier - if annoyingly full of goddamn XML tags all over the place.

I really hope there's a way to compile the XML into binary so that load times aren't ridiculous.
 
rastex said:
I really hope there's a way to compile the XML into binary so that load times aren't ridiculous.
Mozilla is a good preview of an XML driven UI(for better or worse). XAML is almost an XUL ripoff anyway. ;)
 
So how is this going to fit into MS's business OSes? Are they just going to tell companies to stick with XP, or do they really think they can pull of telling everyone that they need to buy new videocards for every system in the office?
 
border said:
So how is this going to fit into MS's business OSes? Are they just going to tell companies to stick with XP, or do they really think they can pull of telling everyone that they need to buy new videocards for every system in the office?

Eventually yes, but the plan is for the 'fluff' to be optional.
 
There are 2 different things at play here: Aero and Avalon.

Avalon, the new programming model for the Windows GUI will be back-ported to XP. I'm not sure about 2000.
It will use the 3d card to render each window but it will not involve 3-d windows as everyone here thinks. It will include XAML and a new .net API for windows (WinFX).

Now, the sample app shown displays images in a 3-d fashion, but that is just the usage by that application. For the most part, windows will still look 2-d, but smoother (like when you drag and move them).

For example, if you have a Dell Lattitude D800 laptop that has a native 1900 x 1200 resolution, you have issues with the current version of windows. At 15.4", that resolution causes text to be very, very small. Change the resolution to any other one (which is not native for that LCD) and you get blurry text. Change the DPI from 96 to 120 and that helps but some graphics look distorted. For example, the size of icons are tied to the resolution which is something you'd expect would be left behind in DOS.

Avalon will fix all of this. In some basic respects, it is moving from bitmap-based visuals to vectors.

Heres a good link...
http://msdn.microsoft.com/theshow/Episode042/Transcript.html


Now, with Aero, that is only on Longhorn and it is the nice new "User Experience"/graphics/look-n-feel, etc. I think this includes the side taskbar, guidelines for developers, a task-based Interface, etc.

http://www.winsupersite.com/showcase/longhorn_aero.asp
 
Also, here is another good link about Longhorn...

http://www.winsupersite.com/showcase/longhorn_preview_2003.asp

It talks about the Desktop Composition Engine, or DCE (code name Avalon), the different Tiers (to support Directx 7 cards), the ability to rescale a window (whereas now you resize it), transparency, smoother video layback, etc.


Again, I'm not sure what the final product will be but this should alleviate some of the concerns about what the intent of this change is.
 
This text that you're reading right now, it's interpreted and rawn by the CPU. the only time the video card comes into the picture is just to send the completed desktop imge to the screen.

On the other hand, if you've got a grapics card taking care of your frontend, the CPU would receive the text, but instead of doing anything with it, it could shoot it straight to the graphics card, wich would render that text into a texture, and paste that texture on a flat polygon that would be the internet explorer window and then shoot it off to the screen without bothering the processor.

So what exactly *will* the 4GHz CPU in my PC be doing while my graphics card is arsing around drawing the interface? Pretty much all your CPU does at the moment is draw the interface - its not exactly a resource hog.

Take that away, and its just sitting there being idle.

If you are actually doing something CPU intensive, like in photoshop, or rendering a movie, the CPU time used by the interface is negligble.

Sure, the 3D looks nice, but that photo browser isn't much different from picasa.
 
another interesting thing is that apparently WGF1.0 and WGF2.0 compliant cards have to exactly match the WGF1.0 and WGF2.0 specs. There is no room for adding stuff that isnt supported if you want WGF2.0 compliance then it MUST do what WGF2.0 requires and nothing more. This means all GFX card makers will basically be making hardware variants of the fixed specs.

This basically moves windows to a "platform" approach for games capabilities. Also it's my understanding that under longhorn drivers will be done away with completely and they will have to be in ROM on each card - this will allows M$ to go almost instant-on with longhorn running on a new machine (we'r talking new mainboard, 64bit CPU, WGF2.0 compliant PCIexpress card etc)

It's also my impression that M$ will go down the route of getting the PC manufacturers to define new PCs by spec - so you will buy a WGF2.0 compliant pc etc

Should certainly simplify the pc market, clean up the desktop interface and allow much faster loading / processing of apps etc

M$ only have one shot to get the 32->64bit change over right - and longhorn has to work. it's finally time to get rid of all the DOS/16/32 bit baggage and start affresh. The change from 64->128bit is probably at least 2 decades away (win3.1 ->win95 ~ 5 years, win95 -> longhorn ~ 10 years) and if they fuck this up like they did with 95 then they will have serious problems

honestly - all these people complaining about "useless" 3D desktops are missing the point and/or dont understand how windows apps work.
 
SO...

What you're all saying is... If I want to build a new PC, I should wait for longhorn because I would only have to build an entirely new one when longhorn is released? >=T
 
not being funny, but if its taking microsoft this long to come up with that, then i wonder what apple has planned, cos i doubt they are aiming tiger at longhorn.

Personally i preffer the way os x is layed out, and looks, but everyone has their own preferences. It also uses 3d to bits of the GUI anyhow, when will mr gates stop steeling ideas from apple! :P
 
10 or 15 years from now, when we're using personal display units (i.e. glasses similar to the one in Mission Impossible 2 intro) and have dual lenses to give us 3D perception, full encompassing overlaying vision...

this will be remembered by some as a critical step towards moving such a new computing paradigm.
 
well, like all things PC there is always something better just on the horizon.. I would say if you need a new PC now go buy one. If not, wait until longhorn to see what pans out

As with all things microsoft some things might change before it launches.. but there will be a huge shift for 64bit over current 32bit pc's and you can already see that with PCIexpress and the new 64bit chips.

If you buy 64bit PC today i'm pretty sure longhorn will work (i think thats the idea) and you'll be able to run longhorn interface on current PCs through XP but all the features of longhorn will only come into play if you build a new pc that uses all the tech longhorn will support as longhorn is a true 64bit OS and does away with 32bit windows compatibility intirely except through emulation AFAIK
 
Top Bottom