Re: vista and VB6

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

No problem, glad to add to the pile. Unfortunately the Vista performans will
'never' be available on my computer ;)) Not even as multiboot. I already
have an issue with a printed circuit board CAD program not installing on XP
:(( So I have a W2k / XP dualboot system already. I am in the bottom a
hardware developer, using VB to control and visualize the workings of that
HW. Before that I was using PowerBasic originating from Borlands TurboBasic.

/Henning

"Mike Williams" <gagamomo@xxxxxxxxxxxx> skrev i meddelandet
news:eYkSePTjIHA.1164@xxxxxxxxxxxxxxxxxxxxxxx
"Henning" <computer_hero@xxxxxxxxxxxx> wrote in message
news:47e6a4a9$0$12243$57c3e1d3@xxxxxxxxxxxxxxxxxxx

With no HW acc. I get: Compiled .exe:
2422 millisecond for the processor to become free
2424 milliseconds for the 1000 blits to actually complete

Thanks Henning. Your help is very much appreciated.

Your previously posted results (685 milliseconds in both cases) confirms
what I had suspected, that your own XP machine is using the video card's
2D hardware acceleration (as is normally the case) but that on your own
system the software (effectively your VB code) actually waits for the
hardware to complete a blit before its sends another one (resulting in
both times being the same 685 milliseconds) whereas on my own XP machine
the first time is just 1 millisecond to complete all 100 blits, indicating
that all 1000 blits are sent to the hardware queue and the software (the
VB code) comes away immediately, leaving the hardware to get on with the
actual job of peforming the 1000 blits on its own, in parallel with
whatever the main processor happens to be doing. There are of course
reasons why some video cards might require the software to wait until they
have actually completed the blit (although those reasons do not actually
apply to your own card which has lots of its own memory) but such
differences are to be expected on vastly different systems, such as my own
system and yours. However, in both cases (my own XP system and yours with
your previously posted set of results) the video card hardware, or to be
more precise the firmware, is clearly being used to perform the blits.

But, of course, as soon as you turn off your video card's hardware
acceleration (as you did when you performed the test which gave the
results you have just posted) the time for your 1000 blits increases
greatly, from 685 milliseconds to 2422 milliseconds, taking almost four
times as long as it did before.

The fly in the ointment in all this is the fact that if you "upgraded" to
Vista on your own machine (the machine that produced the 685 millisecond
result in its standard settings in XP) then you would get a result of 2422
milliseconds, or thereabouts, with all your blits and all your other GDI
drawing and blitting and stretching functions taking four times as long as
they did on XP on exactly the same machine, regardless of the driver you
installed. That's because Vista totally cripples the video card's normal
2D hardware acceleration, having exactly the same effect as if you had
turned it off manually in XP using the TroubleShooting tab. And you cannot
turn it back on, because it has been totally crippled. This will
dramatically slow down any applications that make heavy use of the GDI
functions, such a CAD packages and certain drawing programs, and of course
your VB code. And of course Micro$haft are keeping quiet about the
problem, consigning the information to a secret vault somewhere and
failing to let anyone know about it. That's the stuff I have been
complaining about for ages, but of course nobody is really listening :-(

Anyway, thanks very much for your help Henning. Much appreciated.

Mike








.

Relevant Pages

  • Re: vista and VB6
    ... Your previously posted results (685 milliseconds in both cases) confirms what I had suspected, that your own XP machine is using the video card's 2D hardware acceleration but that on your own system the software actually waits for the hardware to complete a blit before its sends another one whereas on my own XP machine the first time is just 1 millisecond to complete all 100 blits, indicating that all 1000 blits are sent to the hardware queue and the software comes away immediately, leaving the hardware to get on with the actual job of peforming the 1000 blits on its own, in parallel with whatever the main processor happens to be doing. ... There are of course reasons why some video cards might require the software to wait until they have actually completed the blit but such differences are to be expected on vastly different systems, such as my own system and yours. ...
    (microsoft.public.vb.general.discussion)
  • Re: vista and VB6
    ... Blits actually completed after 1490 milliseconds ... Up to now every Vista machine I've tested cripples the 2D acceleration, even with the most up to date drivers installed. ... Private Declare Function BitBlt Lib "gdi32" _ ...
    (microsoft.public.vb.general.discussion)
  • Re: File Fragmentation
    ... The /aic79xx/ driver can also do this, but the kernel ... * The maximum amount of SCB storage in hardware on a controller. ... For my Maxtor Atlas III drives, that have 512-byte hardware sectors, we have: ... Average seek time: 4.5 milliseconds ...
    (comp.os.linux.misc)
  • Re: vista and VB6
    ... Blits actually completed after 1490 milliseconds ... It clearly shows that in Vista the 2D hardware acceleration is not working on your NVidia GEForce 8800 video card, and that the main processor is performing these blits. ...
    (microsoft.public.vb.general.discussion)
  • Re: Fastest way to move a compatibledc into a DC
    ... by the way, when I said in my previous response that the way to get the timing was to put a stop watch on the display I meant that's how to do it in the test code I posted, because I specifically wanted to time the result to "the time that the code loop finished executing" in order to clearly show that the blits were in a queue and that the processor was very rapidly made available for other uses.You can of course instead use two separate "end times" in the code and print them both out so that you can get a printout of the time that the blits actually finished as well as the time the processor was "freed" after the code loop had placed them all in the queue. ... If so then the X1600 2D hardware, which is fairly new and which according to your posted results would be producing 4500 milliseconds, is actually considerably slower than the 3000 milliseconds of my very much older 9600 AGP card? ... I'd be interested in seeing the actual results (fully executed DIB to screen versus fully executed SCB to screen) on your laptop. ...
    (microsoft.public.vb.general.discussion)