Ich projeziere da einfach nur Erfahrungswerte aus meinen Datenbank-Projekten. Wenn ich bei aufwendigen Konvertierungen einen Fortschrittsbalken pflege, kostet das auf klassischen Rechnern ca. 20 - 30% Zeit extra. Da gibt es dann auch mal einen weißen Bildschirm. Auf Rückfrage habe ich dem Kunden erklärt, dass das wie in einem Tischgespräch ist: Wenn man den Mund voll hat, muss/soll man erst fertigkauen (=rechnen), bevor man etwas von sich gibt (=Bildschirm zeichnen), weil es sonst mehr Zeit kostet (=Tischdecke sauber machen vom Sabbern). Das hat bis jetzt jeder verstanden. Wenn ganz schlaue dann sagen, sie hätten aber einen Multicore-Rechner, da könnte man doch mit Threads arbeiten, halte ich eine Frage dagegen: "Wieviel ist Ihnen das wert, denn Sie müssen meine Arbeitszeit dafür zahlen?" Bis jetzt blieb es immer beim weißen Schirm... .Stefan_E hat geschrieben:Warum jetzt allerdings der Update eines Statusbars 100x (also nach jedem Bild) 5 - 30% Performance kosten soll, entzieht sich noch meiner Einsicht - kommt aber auf die Bildaufloesung an: bei 3x5 pixel mag's so sein...
Wenn du große Bilder mit komplexeren Batches bearbeitest, ist die Zeit "dazwischen" durchaus hinreichend lang, dass es auch nach "Absturz" aussieht. Je nach Programmstruktur ist es keine Statusbar die aktualisiert werden muss, denn die liegt auf einem Panel (das auf einem Panel liegt,...) in einem Reiter in einem Fenster, das wiederum in einem Programm. Um da etwas zu aktualisieren, muss man dem Programm sagen: Wart mal mit rechnen, zeichne dein Fenster neu, dann kannst du den Reiter neu zeichnen, der kann die Panel neu zeichnen und dann kannst du die Statusbar neu zeichnen. Denn nur die Statusbar neu zeichnen ändert ja nichts am weißen Fenster, oder? Und darum ging es - glaub ich - eingangs.
Grüße
NoSi