Olaf - I've converted your mandelbrot app
in [VB.NET]
|
From: Mike Williams on 3 Oct 2009 15:01 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:%23PWxDUFRKHA.4568(a)TK2MSFTNGP06.phx.gbl... >> [Mike said] Well in that case [in Vista] you almost certainly >> won't be getting any GDI hardware acceleration either from >> VB.Net or from VB6. Just as a matter of interest, I've heard >> that Micro$oft have had a change of heart and have brought >> back GDI acceleration in Windows7, but I can't confirm >> it because I haven't tried Windows 7 myself . . . > > [Tom said] The same button is greyed out in Win7 64-bit, > and I get virtually identical timings. I think you need to install the appropriate driver. I've done a bit of Googling since I posted my original comment (above) and the way the video hardware is addressed on different versions of Windows under different conditions is (as expected) quite complex, as you'll see at the following link: http://blogs.msdn.com/directx/archive/2009/09/29/comparing-direct2d-and-gdi.aspx Although it is only one page it does discuss the subject at a fairly low level and in terms of what we have been discussing in this thread it boils down to the following (which is an extract directly from the page) . . . .. . . GDI is hardware accelerated on Windows XP, and on Windows 7 when the DWM is running and when a WDDM 1.1 driver is in use. Direct2D is hardware accelerated on any almost any WDDM driver and regardless of whether DWM is in use. There are announced plans to port Direct2D to Windows Vista. Here it will also be hardware accelerated on almost any WDDM driver. On Vista, GDI will always render on the CPU. Mike
From: Tom Shelton on 3 Oct 2009 15:15 On 2009-10-03, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message > news:%23PWxDUFRKHA.4568(a)TK2MSFTNGP06.phx.gbl... > >>> [Mike said] Well in that case [in Vista] you almost certainly >>> won't be getting any GDI hardware acceleration either from >>> VB.Net or from VB6. Just as a matter of interest, I've heard >>> that Micro$oft have had a change of heart and have brought >>> back GDI acceleration in Windows7, but I can't confirm >>> it because I haven't tried Windows 7 myself . . . >> >> [Tom said] The same button is greyed out in Win7 64-bit, >> and I get virtually identical timings. > > I think you need to install the appropriate driver. I've done a bit of > Googling since I posted my original comment (above) and the way the video > hardware is addressed on different versions of Windows under different > conditions is (as expected) quite complex, as you'll see at the following > link: > > http://blogs.msdn.com/directx/archive/2009/09/29/comparing-direct2d-and-gdi.aspx > > Although it is only one page it does discuss the subject at a fairly low > level and in terms of what we have been discussing in this thread it boils > down to the following (which is an extract directly from the page) . . . > > . . . GDI is hardware accelerated on Windows XP, and on Windows 7 when the > DWM is running and when a WDDM 1.1 driver is in use. Direct2D is hardware > accelerated on any almost any WDDM driver and regardless of whether DWM is > in use. There are announced plans to port Direct2D to Windows Vista. Here it > will also be hardware accelerated on almost any WDDM driver. On Vista, GDI > will always render on the CPU. well... My driver is reporting as a WDDM 1.1 driver. But, I'm downloading the lates windows 7 driver from nvidia right now, to see if that changes anything... -- Tom Shelton
From: Tom Shelton on 3 Oct 2009 15:45 On 2009-10-03, Tom Shelton <tom_shelton(a)comcastXXXXXXX.net> wrote: > On 2009-10-03, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: >> "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message >> news:%23PWxDUFRKHA.4568(a)TK2MSFTNGP06.phx.gbl... >> >>>> [Mike said] Well in that case [in Vista] you almost certainly >>>> won't be getting any GDI hardware acceleration either from >>>> VB.Net or from VB6. Just as a matter of interest, I've heard >>>> that Micro$oft have had a change of heart and have brought >>>> back GDI acceleration in Windows7, but I can't confirm >>>> it because I haven't tried Windows 7 myself . . . >>> >>> [Tom said] The same button is greyed out in Win7 64-bit, >>> and I get virtually identical timings. >> >> I think you need to install the appropriate driver. I've done a bit of >> Googling since I posted my original comment (above) and the way the video >> hardware is addressed on different versions of Windows under different >> conditions is (as expected) quite complex, as you'll see at the following >> link: >> >> http://blogs.msdn.com/directx/archive/2009/09/29/comparing-direct2d-and-gdi.aspx >> >> Although it is only one page it does discuss the subject at a fairly low >> level and in terms of what we have been discussing in this thread it boils >> down to the following (which is an extract directly from the page) . . . >> >> . . . GDI is hardware accelerated on Windows XP, and on Windows 7 when the >> DWM is running and when a WDDM 1.1 driver is in use. Direct2D is hardware >> accelerated on any almost any WDDM driver and regardless of whether DWM is >> in use. There are announced plans to port Direct2D to Windows Vista. Here it >> will also be hardware accelerated on almost any WDDM driver. On Vista, GDI >> will always render on the CPU. > > well... My driver is reporting as a WDDM 1.1 driver. But, I'm downloading > the lates windows 7 driver from nvidia right now, to see if that changes > anything... > Actually, it did - a little (VB6) MT: 1.65 1.66 1.66 ST: 2.96 2.94 2.91 VB.NET MT: 1.563 1.564 1.547 ST: 2.953 2.953 2.985 Looks almost identical - with a very slight advantage to the vb.net threaded version. This was run on windows 7 64-bit not on vista with the lates nvidia windows 7 drivers. Everything else is the same - it's the same hardware as my vista install. -- Tom Shelton
From: Mike Williams on 3 Oct 2009 17:52 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:%23EZRb3FRKHA.1236(a)TK2MSFTNGP05.phx.gbl... > well... My driver is reporting as a WDDM 1.1 driver. But, > I'm downloading the lates windows 7 driver from nvidia > right now, to see if that changes anything... As I've said, I have no experience whatsoever of Win7, but according to various sources I've read it is supposed to give back the GDI hardware acceleration that is missing from Vista, as long as the correct drivers are installed. Whether that is true or not I really have no idea. In a real app the effect of hardware aceleration will often be masked by other things it is doing, and in any case it is always possible with today's very fast machines that you have a very powerful main processor coupled to a relatively humble (by today's standards) graphics card, and in such cases the difference between the speed of a hardware blit and the speed of a software blit might not be a lot. I think if you want to check for hardware acceleration you're probably better off writing some code that does nothing else except Blit from one screen compatible DC to another in a loop, and time the loop. If the timer indicates that loop has finished executing extremely quickly (typically in less than a millisecond even for a large number of fairly large blits and long before the blits can possibly have been actually completed) then the blits are almost certainly being done in hardware and you will only see the final blit long after the code actually finished and timed out. I don't know how Win7 behaves in relation to its screen display, but in XP I used to write a loop to repeatedly blit a bitmap from a memory screen compatible DC to the display and after the final blit draw a circle or something on top of the last blit, with a timer (or perhaps just a call to Beep) indicating when the code had finished and the appearance of the circle indicating when the blits had finished. How that would go in Win7 I have no idea. Mike
From: mayayana on 4 Oct 2009 10:35
> > Yes, it does. That's why I've always said that >> if the likes of McCarthy and > > Clark and Ligthert stop deliberately causing >> trouble in the VB6 group then I > > (and presumably others) will immediately stop retaliating :-) > > Mike - you and yours cause as much trouble as > we .net'rs do. You invite the > problems by the way you malign .net when people > accidently post. Can't you > just redirect and let it go? You and mayayanna are > the worst that way. > Beg your pardon?! I have *never* maligned .Net people who post in the VB6 group. People end up posting in the VB group because Microsoft has deliberately caused confusion as part of their marketing. They started out with VB and added .Net. Then they dropped the ".Net" from VB.Net and started calling it VB. People can argue all day that VB.Net is the next version of VB, but when the dust settles, it's simply a lie. VB is for compiled Windows software. VB.Net is a Java clone, with different strengths. I've been using VB for 10 years, yet VB.Net code "is all Greek to me". And it's mostly based on the .Net objects/classes, which are not part of VB and are therefore unknown to VB developers. People think they're using "VB" but their code is simply not recognizable as VB. If we give them a VB solution to their problem, that code will be unrecognizable to them. People often post in the VB group and then get impatient because they think it must be splitting hairs to distinguish between VB and VB.Net. "It's all VB, right? Why do you have to be so picky about where I post?" I don't blame those people. It's not their fault. They've been systematically misled. But we can't help them. So the best I can do when someone wanders into the wrong group, asking about .Net in the VB group, is to explain the landscape so that they know, once and for all, which group to go to and so that they won't be confused in the future when they encounter 2 kinds of VB in newsgroups, code samples, etc. One way or another, sooner or later, these people will have to learn the dirty little secret that VB.Net is not actually very much like VB. So why not just explain the clear facts to them at the start, rather than leaving them to flounder, getting confused over and over by inconsistencies in the code samples they run across, until, like a child learning the facts of life, they eventually manage to piece together the unspoken details for themselves? This has nothing to do with being against .Net. It's just a matter of putting the facts on the table. But unfortunately, the facts do not reflect well on Microsoft. Microsoft wants to phase out VB, phase out 3rd-party API programming in general, and move people to .Net, pretending that it's a natural migration. And somehow Microsoft has convinced some .Net people that anyone who chooses to stick with VB or another compiled language is holding up .Net's progress. So providing the plain facts, that VB.Net is not VB and that C# is not C++, turns out to be quite an incendiary undertaking. :) |