In Figure 10.6, we show the essential data we found when we ran WAP on the Solitaire cascade. We start apf32cvt, and then SOL.EXE. We clear the counters first with apf32dmp because we don't want to see all those API calls that occur during the initialization of Solitaire (that's another performance problem to deal with separately). Then we press SHIFT+ALT+2 to start the cascade. When the cascade is complete, we dump the data.
Figure 10.6 GDI32.DLL activity during the Solitaire cascade
Very interesting. We would have guessed that the program was spending a lot of time in the BitBlt routine putting the card images on the display, and it is. But what about all that time in GetPixel and SetPixel? There were almost 12 calls to each routine for every BitBlt call! Most of the time was spent there. And by the rules outlined in the last chapter, both of these calls cross the client-server boundary so they will be flushing the batch in the bargain.
It's time to take a step back and think about what we've discovered. We have card images flowing all over the screen, and on top of that we set individual pixels. No way could a user see those individual pixels, so this definitely seems an excessive refinement. We want to want to find out why Solitaire is making so many of these calls during the cascade. To do that we have to move on to another tool called CAP. But first, we clean up the WAP conversion.