M
Jetzt habe ich das erstmal Verstanden :p
Diesen Effeckt konnte ich schon oft beobachten und das Verhalten kann ich auch nur Vermuten durch meine Beobachtungen.
Vermutung:
Ich habe eine Farbtiefe von 32Bit, also ist das Fenster entsprechend so gezeichnet, wenn ich nun eine große Bitmap mit einer Tiefe von Vermutlich 24Bit auf dieses Fenster Blitte, welche nur aus Nullen besteht, also jedes Byte 0 ist, muß BitBlt erst Feststellen ob es 24Bit und nicht 32Bit ist damit es nach den größen Angaben passt, wurde aber auf die Bitmap gezeichnet, so weiß BitBlt das dieser DeviceContex jene Größe und Farbtiefe hat und muß dieses nicht erst identifizieren.
Würdest du z.B. nicht komplet auf einmal blitten sondern das unterteilen in 8x6 Kacheln, so würde es schneller sein da bei der ersten kachel schneller eine Identifizierung durchgeführt wird und bei den nächsten nicht mehr.
Oder anders gesagt, BitBlt hat Probleme um so mehr 0én vorhanden sind.
Deswegen empfehle ich FillRect() da dabei mit einem HBrush gezeichnet wird und somit die Bitmap eindeutig ist, BitBlt blittet einfach nur 0én rein.
Ob das nun tatsächlich in diesem Zusammenhang steht oder nicht, kann ich nicht sagen, aber eins ist Gewiss, je mehr 0én, bzw. um so größer ein "leeres" Bild um so langsamer wird es (46-48ms bei mir) lade ich eine "bunte" Bitmap und blitte diese ständig, als zu löschen, dauert es nur paar Millisekunden.