VDR Portal

Ich melde mich freiwillig

Hi Igor!

ja, würd mir gerne mal den Code anschauen und das Programm ausprobieren...

20ms sind übrigens gar nicht notwendig, 40ms reichen. Ich weiss grad nicht auswendig wie es in der 0.1.1 gelöst wurde, aber die 20ms waren an einer Stelle (sollten ja 2 sleeps sein) nur dazu da, um 100% CPU Last zu vermeiden, wenn kein Bild vom Treiber bezogen werden kann. Ursprünglich hat der Treiber selbst den Takt vorgegeben, immer wenn ein Bild gegrabt war wurde die Berechnung durchgeführt, das war dann alle 40ms.

Aber das schau ich mir gern mal in deinem Code an!

Grüße,
Simon

@Samc

ich hab das mit den Sleeps eigentlich zu 100% aus dem VDR Atmo Plugin übernommen... ein was ist allerdings höchst seltsam solange ich nur den normalen Desktop verwendet ohne Videoanwendungen hab ich ne CPU Last < 1%! -- sobald ich aber ein Video via VideoLan oder Windows Mediaplayer anspiele geht die CPU Last von meinem AtmoWin auf ca 25%? (auf einem AMD 4600 X2!) ... und der Wert sinkt auch nicht wieder wenn ich VLC bzw. MediaPlayer beende...?

Igor

[EDIT]
ich glaub ich hab einen Grund gefunden - ich hab was verschlimmbessert in der Annahme nen Fehler im Source des Atmo Plugins zu beheben... schau mal in die Datei "AtmoDisplayCaptureInput.cpp" Methode Execute()

ich messe da wie lang mein CalcColors getdauert hat mit Gettick Count

wenn das weniger als 20ms gedauert hat - ware ich den Rest ... im Originalsource stand da - wenns weniger als <20ms gedauert hat - warte auf jeden fall noch 20ms bis zum nächsten Frame...

Quoted

DWORD CAtmoDisplayCaptureInput::Execute(void) {
// process Screen Capturing... every x ms ...
DWORD tickCount;
while (this->m_bTerminated == FALSE) // in this loop the picture is read and the colors are calculated
{
tickCount = GetTickCount();

CalcColors(); // read picture and calculate colors

tickCount = GetTickCount() - tickCount;
if (tickCount < 20) // wait 20ms to avoid 100% CPU usage
{
// org: this->ThreadSleep(20); // hab ich für Fehler gehalten?
if(this->ThreadSleep(20 - tickCount) == FALSE)
break;//sleep wurde durch thread terminate beendet!
}
}
return 0;
}

(ThreadSleep -> ist spezielles Sleep was abgebrochen wird - wenn der Thread zu Beendigung aufgefordert wird...)

ich sollte wohl - einfach die 20 durch 40 ersetzen und gut ist ... so liefert der Thread 25 screenshots pro sekunde - statt 50ms... das dürfte aber nicht erklären warum die CPU Last nach dem starten von VideoLan bzw. Mediaplayer so extrem hoch geht...
..

Hi,

ja du kannst ruhig die 20 durch 40 ersetzen. Kann dann zwar Interferenz zwischen dem Videobild und atmo geben, dürfte abber immernoch nicht auffallen wenns um einen Frame zu spät reagiert.

Woher aber die 25% CPU liegen, das weiss ich auch nicht. Kannst ma mal deutlich länger verzögern, 200ms zB...

Wie gesagt, das hält man leicht für einen Fehler, wenn man nicht weiss, dass der DVB Treiber den Takt vorgibt! Bei Softdevice klappt das mein ich nicht und atmo läuft wirklich mit 20ms Takt, geht aber auch.

Grüße,
Simon

Hi Simon,

die 25% CPU Last sind wirklich lästig... das passiert selbst wenn ich den MediaPlayer nur als kleines Fenster auf dem Desktop habe - dann steigt die CPU Last von meinem AtmoWin plötzlich darauf an... muss ich heut nochmal untersuchen... welches Windows API Aufrufe da so extrem anwachsen...

kann ja eigentlich nur BitBlt bzw. GetDibBits sein... warum frag ich mich nur... - ein Effekt vom Grafiktreiber wenn ein Overlay oder was auch immer aktiv wird? -- wäre halt interessant ob das andere auch beobachten - z.B. auf Windows XP -- ich nutze auf meinem Entwicklungs PC .. Windows 2000.

Solange ich halt nur den Deskop habe - und ein paar Fenster darauf hin und her schiebe ... hab ich selbst bei 20ms Wait - nur <2% CPU Last...


Igor

@Igor

Zum Thema vlc:

Quoted

da hätte mans dann auch nur mit bestenfalls PAL Auflösung zu tun

Ich verwende vlc zum Abspielen von HD (1080i transportstreams). Bei PAL bleibt es bei mir daher nicht.

swifty

@swifty99
du nun wieder :-)*g* mach mirs nur ruhig schwer... ich will ja nur davon weg... irrsinnigerwelche ständig Screenshots zu ziehen für die Ausgabe - und somit sicherlich viel unnötige CPU Last zu erzeugen... daher halt die Idee wenn man die Bildbeschaffung direkt in den Player verlagern könnte... dann würde AtmoLight auch im Fenstermodus des Players funktionieren... hätte ja was für sich?

Oder ist hier jemand der es schafft mir ein funktionierendes Grundgerüst für einen DirectShow Filter zu schreiben - der sich in den Ausgabeprozess einklingt? und das dort die notwendigen Bilddaten abgreift? - freiwillige?


Igor

Hi Igor,

habs vorher mal kurz gestartet: gab sofort 90% Last auf meinem Centrino 1400MHz.

Wäre wohl geschickt zu ermitteln, wo die Rechenzeit verloren geht :-)

Grüße,
Simon

Hi Samc,

mmh - autsch .. ich wollte das auf ne P4M-1800 ausführen ;-)

Die Last tritt aber hoffentlich nur im LiveView auf?

kannst du dir den Source runterladen und selber kompilieren?
- tippe mal auf die "AtmoDisplayCaptureInput.cpp" wo das Bild kopiert wird... ich hatte auch dort schon mal mit StretchBlt ohne Interpolation probiert - das hatte auch ne jämmerlich hohe CPU Last verursacht...

zur Zeit hab ich es so gemacht - ich leg mir am Anfang des Threads nen Bitmap an so gross das der Screenshot 1:1 reinpasst - und kopier dort immer mit BitBlt den aktuellen Bildinhalt hinein...

dann lass ich mir die gewünschten Bildzeilen als PixelBuffer geben - und spare so die vielen GetPixel aufrufe... hab eigentlich gedacht damit krieg ich die CPU Last besser in den Griff... ;-) nix wars...

geht die suche halt weiter - wäre jetzt halt interessant - ob es wirklich am BitBlt liegt, oder der Aufruf zur Ermittlung der Pixelzeile solange dauert... andernfalls mach ich heute Abend ... mal ein paar Messungen... bzw. ne spezielle DebugVersion um dieses Problem zu finden...

Igor

Soa, bin jetzt auch mal dazu gekommen zu testen. Soweit funktioniert das angepriesene, nur das Live-Bild scheint noch richtige Schwierigkeiten zu machen (wie bereits erwähnt):

• ohne Video Last von etwa 1%
  
• während/nach einem Video ~20 %
  
• Interpolation funktioniert nicht?
  

Ich hatte beim Testfilm das Gefühl, das direkt zur neuen Farben gesprungen wird, ohne überhaupt zu interpolieren. Kann das sein?

Die Farbwechsel funktionieren soweit wie sie sollten. Aber das sind ja auch nur spielereien... ;-)

Falls ich mal die Tage Zeit finde, werde ich mir mal die "neue" Routine anschauen, was ich bisher noch gar nicht gemacht habe. Wegen der Diskussion habe ich aber auch noch eine Frage: sind denn 25 screenshots pro sekunde überhaupt notwendig? Ist es nicht sinnvoller, einen neuen Screenshot nur dann zu machen, wenn er angefordert wird? Ich kann mir nicht vorstellen, dass das eine allzu große Verzögerung wäre.

@Matthiaz
habe das jetzt auch mal probiert - d.h. nur alle 40ms einen Screenshot gemacht - und auch die Umsetzung des Screenshots auf das AtmoLight im selben Timing...

Quoted

während/nach einem Video ~20 %

das ist ja die Interessante Frage... warum das passiert...

Quoted

Interpolation funktioniert nicht?

habe eigentlich den Code vom Linux Plugin 1:1 übernommen - könnte höchstens sein das bei der C/C++ Akrobatik - der Visual Studio Compiler irgendwas anders übersetzt? wegoptimiert??

Quoted

Ich hatte beim Testfilm das Gefühl, das direkt zur neuen Farben gesprungen wird, ohne überhaupt zu interpolieren. Kann das sein?

mmh - es wird IMHO nicht interpoliert - sondern nur bei der Ausgabe die vorherigen Farben mit berücksichtigt... wenn ich nicht irre und den Code richtig verstanden habe...

Igor

Du hast recht: es wird nicht mehr interpoliert sondern je nach Farbabstand: kleinere Abstände werden immer noch gefadet, große allerdings mit einem Schlag. Dadurch hat man bei schnellen Wechseln eine unheimliche Dynamik (wohl auchh wegen der vielen gesampelten Bilder), was mir sehr gut gefällt. Der alte Code war ja eher träge.

Wegen der CPU-Last: ja, der Fehler steckt oft im Detail... Was passiert denn, wenn man den Thread einfach alle 5 Minuten oder so einfach resettet. Also Quasi einen "Neustart" simuliert? Ist dann die hohe Last weg? Weil einfach auf statisch schalten und wieder zurück funktioniert nämlich nicht.

Ich lass das Programm morgen auch mal einfach ein wenig im Hintergrund weiterlaufen mit der hohen Last. Evtl. verschwindet sie ja nach einer Zeit (die Hoffunung stirbt zuletzt)...

Danke nochmal an Dich Igor, dass Du soviel Zeit inverstiert hast. Ich denke, dass wir bald das Linux-Pendant in Funktionen ausstechen werden. :-)

- so für heute - fazit:

ein Problem war - ich hatte mir das Bitmap Objekt (CreateCompatibleBitmap) - einmal erzeugt und über die gesamte Laufzeit behalten - war als Optimierung gedacht .. solange sich die Bildschirmauflösung nicht ändert wäre das ja sinnvoll gewesen?

Aber scheinbar passiert irgendwas mit dem HBitmap und den DeviceContexts? was ich mir nicht erklären kann sobald ein Videoplayer startet scheint sich da irgendwas zu verdrehen...

Also hab ich das CreateCompatibleBitmap wieder in Berechnungsroutine aufgenommen... damit ist erstmal der Effekt - weg das die CPU Last nach dem Ende des Videoplayers hoch blieb... jetzt geht sie also wieder runter... aber für meinem Geschmack sind 10-15% CPU immer noch zu hoch... auf einem X2 4600!

Zusätzlich habe ich das Konzept vom VDR Atmo Plugin das abholen des nächsten Bildes via Thread - vorerst aufgegeben - und hole das Bild direkt im Effect Thread (CAtmoLiveView.cpp) vom Bildschirm ab.
- das mache ich ca. 20 mal je sekunde (50ms delay)

Der Effekt das die Überblendungen nicht so weich sind - scheinbar kein Fading statt findet - vermute mal meine Parameter sind da noch irgendwo falsch? vielleicht hab ich mich bei der Initialisierung vertippt? oder sind die Defaultwerte aus dem Original Linux Source nicht optimal?


Igor

@Matthiaz
kannst dir ja gleich nochmal ne neue Version ziehen - mal schauen wie die CPU Last sich jetzt bei dir verhält?

(allerdings ist jetzt der Code von CAtmoDisplayCaptureInput und CAtmoLiveView nicht gerade hübscher geworden -- enthält jede Menge probiererei... ;-))

CAtmoDisplayCaptureInput ist derzeit noch ein CThread - daraus wird eine Simple Klasse denk ich - weil ein weiteres Problem ist in der Linux Version erfolgt zwischen dem Ausgabe Thread und dem Capture Thread keinerlei Synchronisation auf den Zugriff der Capturedaten ... das kann eigentlich nicht gutgehen? oder?
-- oder versteh ich das falsch? was passiert beim Aufruf von
GetColorPacket()? -- da wird doch ne Kopie der Struktur aus dem Input Thread zurückgeliefert? was passiert wenn der InputThread die Quellstruktur gerade neu füllt? was bekommt man da?

Es kommt dabei auch recht oft vor - das der Outputthread 2x mit den gleichen Daten gerechnet hat - weil der Capture Thread noch nicht soweit war neue Daten bereitzustellen...bzw. gerade damit beschäftigt.
...da ich derzeit eh keinen zweiten Input Wüsste - und ein DirectShowFilter eh anders gemacht sein muss - würde ich die Funktion CalcColors() des InputThreads einfach mit in CAtmoLiveView() - einbauen und fertig??

welche guten Gründe? gibt es das Capturen() und Ausgeben() in zwei verschiedenen Threads zu machen?

Igor

Hi,

so jetzt bin ich auch wieder da!

o Das schnelle Überblenden ist genau das, was der intelligente Filter bewirkt. (->Sprungerkennung) Das kann man genau so empfindlich einstellen wie man will (-> Filter_MeanThreshold)

Die "optimalen" Parameter muss jeder für sich selbst finden, man kann das Verhalten von atmo da gewaltig beeinflussen.


o Leider habe ich keine win-Entwicklungsumgebung, kann mir den code also nur anschauen und was dazu sagen :-)


o Der Grund, warum Capture und Calc in 2 Threads geteilt wurde hatte was damit zu tun, verschiedene Einhabemethoden einzubinden, genau weiß das Samael. Für die Win-Version machts aber in meinen Augen keinen Sinn, Capture und Calc sollen also ruhig in einem Thread direkt hintereinander laufen.

Wichtig ist nur, dass der Filter und die Ausgabe getrennt vom Calc mit einer festen Frequenz laufen!

Interesant wäre es sicher noch zu wissen, mit welcher Frequenz sich die Daten im Bildpuffer von Win ändern...schneller muss das Ganze ja auch nicht laufen. Toll wäre es, auf genau diese Änderungen zu warten und genau danach zu capturen; zusätzlich sollte freilich eine max. Frequenz beachtet werden.

Wie das geht weiss ich leider auch nicht...bin im Moment eher der Theoretiker, da ich ja auch gar nix compilieren kann; viell. hilfts euch ja.

Grüße,
Simon

Quoted

Original von Igor
@Matthiaz
kannst dir ja gleich nochmal ne neue Version ziehen - mal schauen wie die CPU Last sich jetzt bei dir verhält?

Hab mir grade die neue aus dem Debug Ordner gezogen.

Also: ohne Video ist live bei etwa 1%. Mit Video (relativ egal ob Windows Media Player, Media Player Classic oder VLC) ist Last zwischen 15-20%. Beim Beenden danach sofort wieder auf auf etwa 1% (das alles auf Arbeitsrechner AMD 3500+).

Interessant ist, dass man nichtmal ein Video braucht: es reicht, den WMP zu öffnen und nichts machen zu lassen -> direkt 10% Last bei AtmoWinA. Da scheint irgendwas deftig zu kollidieren... ;-)

@Samc

Quoted

Das schnelle Überblenden ist genau das, was der intelligente Filter bewirkt. (->Sprungerkennung) Das kann man genau so empfindlich einstellen wie man will (-> Filter_MeanThreshold)

richtig ---> der Wert kann unter HKEY_LOCAL_MASCHINE\software\AtmoWinX\LiveViewFilter_MeanThreshold verändert werden.

Quoted

Leider habe ich keine win-Entwicklungsumgebung, kann mir den code also nur anschauen und was dazu sagen :-)

schade... naja ein kritischer Blick kann ja auch schon manchmal mehr helfen ...

Quoted

o Der Grund, warum Capture und Calc in 2 Threads geteilt wurde hatte was damit zu tun, verschiedene Einhabemethoden einzubinden, genau weiß das Samael. Für die Win-Version machts aber in meinen Augen keinen Sinn, Capture und Calc sollen also ruhig in einem Thread direkt hintereinander laufen.

mmh - macht selbst da keinen Sinn extra Threads zu verwenden - kann man ja zwei normale Klassen nehmen?
-- AUßER! wenn man das Capturen aus Zeitgründen - parallel zur Ausgabe machen will -- allerdings sollte dann der Zugriff auf die ColorPacket Struktur besser geschützt werden? Mittels Mutex? CriticalSection oder was auch immer ... weil wie es derzeit ist seh ich die Gefahr "halbe Daten" zu bekommen.

@Samael: ? stimmt das so? wie ich da sehe? oder macht Linux bzw. eure Threadbibliothek da was implizit was ich nicht im Quellcode sehe?

Quoted

Wichtig ist nur, dass der Filter und die Ausgabe getrennt vom
Calc mit einer festen Frequenz laufen!

richtig. - allerdings macht es nicht viel Sinn wenn die Ausgabe Frequenz viel höher liegt - als die "Capture Frequenz" und somit das gleiche ColorPaket mehrfach durch die "Mangel" gedreht wird? -- also müsste man versuchen den Takt des OutputThreads irgendwie an den Capture Thread zu binden.... --> z.B. über ein Event? (CreateEvent(...), WaitForSingleObject(...) -- construct - was der Capture Thread auslöst wenn er ein Frame hat -- ?

Quoted

Interesant wäre es sicher noch zu wissen, mit welcher Frequenz sich die Daten im Bildpuffer von Win ändern...schneller muss das Ganze ja auch nicht laufen. Toll wäre es, auf genau diese Änderungen zu warten und genau danach zu capturen; zusätzlich sollte freilich eine max. Frequenz beachtet werden.

tja das wird wohl ein Gehemnis bleiben... früher unter win9x gabs mal die Möglichkeit ein paar Hooks direkt in den Grafikausgabe Engine von Windows (DDI Hooks) zu hängen -- das gibts aber leider nicht mehr... ist auch von Microsoft aus den Dokumentation getilgt wurden.


Unser Hauptproblem worüber man sich den Kopf zerbrechen kann ist - warum dauern bestimmte GDI Funktionen - normalfall weniger als 1ms! z.B. BitBlt oder GetDibBits(..) ... aber sobald ein Videoplayer läuft - steigt deren Ausführungszeit (16ms!) / CPU Usage undefiniert an?

Igor

Quoted

Also: ohne Video ist live bei etwa 1%. Mit Video (relativ egal ob Windows Media Player, Media Player Classic oder VLC) ist Last zwischen 15-20%. Beim Beenden danach sofort wieder auf auf etwa 1% (das alles auf Arbeitsrechner AMD 3500+).

ist ja schonmal ne Verbesserung ;-) --allerdings musst du auch bedenken im Gegensatz zu "deiner" Software holt diese nicht 1000 Pixel sondern 64x48Pixel ab ... versuch mal bei deiner Software soviele Pixel zu holen - mal gucken wie sich dann die CPU Last verhält? - nur aus neugierde? obs da auch passiert und nur nicht so auffällt bei 1000 Pixeln?

Quoted

Interessant ist, dass man nichtmal ein Video braucht: es reicht, den WMP zu öffnen und nichts machen zu lassen -> direkt 10% Last bei AtmoWinA. Da scheint irgendwas deftig zu kollidieren... ;-)

Ja... nur was... ich weiss nur soviel das die CPU-Last Ausführungszeiten von BitBlt und GetDibBits Sprunghaft ansteigen - soweit man das mit GetTickCount messen kann - im Idle Desktop kommt da eigentlich immer ne Satte 0ms raus ... sobald ein Overlay? Videoplayer oder was auch immer aktiv wird - steigt die Zeit sprunghaft auf 16ms und mehr an .... ich nehm an es hat irgendwas mit dem Hbitmap Objekt zu tun... aber so recht erklären kann ich mir es nicht - warum geht die CPU Last nicht zurück wenn ich das gleiche HBitmap für die gesamte Laufzeit verwenden will ... und nur immer wieder überschreiben?

Igor

Quoted

Original von Igor
ist ja schonmal ne Verbesserung ;-) --allerdings musst du auch bedenken im Gegensatz zu "deiner" Software holt diese nicht 1000 Pixel sondern 64x48Pixel ab ... versuch mal bei deiner Software soviele Pixel zu holen - mal gucken wie sich dann die CPU Last verhält?

Also mit der 0.35er Version und dem GetPixel() Routinen habe ich etwa 2-4% Last unabhängig von Videos/Overlays und mit Einstellungen:

• PPK=5000 (Pixel/Kanal)
  
• Bänder = 10
  
• Einteilung = 40
  
• Bildabfrage = 50ms
  
• Interpol.Schritte = 50
  
• Int.-Pause = 25
  

Setze ich Interpol.Schritte = Int.-Pause = 0 steigt die Last bei den obigen Parametern auf etwa 20% an. Allerdings berechnet der Filter jetzt auch 20.000 Punkte alle 50ms, also 400.000 Bildpunkte/Sekunde. Jetzt macht sich auch hier (!!!) der "Video-Bug" bemerkbar: mit WMP nochmal 15% mehr Last, also etwa 35%.

Du berechnest etwa 3000 * 25 = 75.000 Bildpunkte/Sek bei einer Last von etwa 3%.

Bei PPK = 1000 (also 4*1000*20 = 80.000Pixel/Sek) hat der alte Ansatz übrigens auch etwa 3% Last, allerdings bleibt dieser mit WMP konstant zwischen niedrigen 2-4%.

/Edit: Wobei die visuelle Ausgabe vom neuen Filter natürlich ungleich besser ist als die vom alten bei diesen Einstellungen.
Als Fazit kann man sagen: beide Methoden haben diesen lästigen Bug, allerdings fällt er bei der alten Methode nicht auf, da durch die Interpolation künstliche Pausen eingefügt worden sind, die nun nicht mehr vorhanden sind. Als Workaround könnte man AtmoWinA einfach mit niedriger Priorität starten... ;-) Spass beiseite: offensichtlich sind diese C++-Pixelgrabber wohl anfällig gegenüber jegliche Art von Overlays. Tritt dieser Bug (hohe Last einfach nur mit WMP offen) eigentlich auch bei VNC auf?

@Matthiaz

Quoted

Als Fazit kann man sagen: beide Methoden haben diesen lästigen Bug, allerdings fällt er bei der alten Methode nicht auf, da durch die Interpolation künstliche Pausen eingefügt worden sind, die nun nicht mehr vorhanden sind. Als Workaround könnte man AtmoWinA einfach mit niedriger Priorität starten... ;-) Spass beiseite: offensichtlich sind diese C++-Pixelgrabber wohl anfällig gegenüber jegliche Art von Overlays. Tritt dieser Bug (hohe Last einfach nur mit WMP offen) eigentlich auch bei VNC auf?

ja VNC erzeugt auch diesen Effekt - egal ob ich die Ausgabe via DirectDraw oder OpenGL mache...

Also mein Verdacht ist??
- solange die Grafikhardware nix zu tun - hat wird bitBlt / getDibBits vielleicht von der Hardware unterstützt... sobald ein Overlay oder ähnliches aktiv wird - steht die Hardware funktion für die GDI nicht mehr zur Verfügung? und GDI schaltet um auf Software? ... wäre meine Vermutung... ich hab jetzt mal in Delphi noch ein paar kleine Tests gemacht mit anderen BitBlt Möglichkeiten ... aber vielversprechender ist das auch nicht...

Die Funktionen zur Berechnung der Ausgabe - fallen bei der CPU Last eigentlich kaum ins Gewicht... es sind ausschliesslich die Funktionen der GDI, welche da "austicken". habe das Gestern mal mit GetTickCount gemessen von den 20-40ms was während VLC läuft die Bearbeitung eines Frames dauert gehen 99% nur für BitBlt und die Funktion drauf welche die Pixeldaten in das HSV Image umwandelt... (HSV Umrechnung ist es aber nicht) es sind wieder nur die Pixelzugriffe - habe ja schon zwei Varianten im Source ... einmal via GetPixel(...) mit vorberechten Sourcekoordinaten so ähnlich wie im alten Programm. Als Variante 2 weil ich die x. tausend Aufrufe von GetPixel vermeiden wollte lass ich mir vom Screen-Copy-Bitmap immer die aktuelle Bildzeile als Buffer geben - wo ich die Pixel direkt aus dem Speicherblock kopieren kann... allerdings nimmt sich das nicht viel ob man nun 64 x GetPixel in der X-Schleife macht -- oder ausserhalb einmal GetDibBits(...) für die ganze Bildzeile (bei mir 1600 Pixel also 6400 Byte) ...

Also trifft für unseren Fall und meine 1600 x 1200 Auflösung ungefähr das zu
Zeit(3072 * GetPixel(x,y)) == Zeit(48 * GetDibBits( ... ))

liegt denke ich mal daran das das Verhältnis von mit getDibBits geholten Pixel zu Nutzpixel mit 64 : 1600 einfach zu gering ist - um den eigentlichen Performancevorteil von GetDibBits gegenüber GetPixel auszuspielen? oder?

Igor