Statusbalken bei Stapelverarbeitung

Moderator: Hoogo

User avatar
NoSi
Betatester
Posts: 984
Joined: Mon 07 Jan 2008 19:52
Location: Braunschweig

Re: Statusbalken bei Stapelverarbeitung

Post by NoSi » Tue 13 Oct 2009 08:51

Stefan_E wrote: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...
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... .

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
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer und ausschließlich die aktuellste Beta-Version.

JulianZI
Mitglied
Posts: 711
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Statusbalken bei Stapelverarbeitung

Post by JulianZI » Tue 13 Oct 2009 12:38

Hallo,

das Verhalten während der Stapelverarbeitung hat mich auch schon gestört.

Hier würde sich ein Dialog anbieten, der anzeigt welches Bild gerade geladen und bearbeitet wird.
Manche Programme zeigen auch ein Thumbnail des Bildes. Ich glaube eine solcher Dialog wäre ein netter facelift.

Dass ein Fortschrittsbalken nennenswert Zeit kostet wäre mir neu. Allerdings schaltet man bei der Datenbank die Anzeige der Eingabefelder,Tabellen u-ä. aus, während ein Prozess läuft, der den Datenbank Cursor verändert.

Bei PL32 ist es ähnlich. Hier ist die Bildschirmanzeige abgeschaltet, da im Hintergrund die diversen Bildmanipulationen laufen. In Windows würde der Bildschirm sowieso nur gezeichnet, wenn das Programm nicht beschäftigt ist. Windows löscht aber trotzdem den Hintergrund selbsttätig und damit hat man dann das weisse Fenster.

Die Lösung ist hier, anstatt die Ausgabe abzuschalten einen internen screenshot (eine bitmap) vor dem Anlaufen des Prozesses zu machen und den Bildschirm dann aus diesem screenshot wiederherzustellen. So mache ich das zumindest bei meinen Programmen. Wichtig ist dann aber, dass das Programm durch den Prozess nicht blockiert wird, die Anzeige also wirklich aufgerufen wird.

Grüsse,
Julian

marduk4all
Mitglied
Posts: 132
Joined: Mon 02 Feb 2009 23:26

Re: Statusbalken bei Stapelverarbeitung

Post by marduk4all » Tue 13 Oct 2009 15:01

@JulianZI
Endlich mal eine vernünftiger Post aus Anwendersicht. Danke dafür.
---------------------------------
In meinen Augen ist das ein Fehler und das bleibt auch so. Wenn ich ein
Fenster minimiere, will ich es auch wieder maximieren können. Alles
andere ist unlogisch. Jetzt behaupte noch einer das Gegenteil (möglichst in
einem langen gequollenen Post).

Gruß
Andreas

JulianZI
Mitglied
Posts: 711
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Statusbalken bei Stapelverarbeitung

Post by JulianZI » Tue 13 Oct 2009 16:07

Hallo,

So richtig verstehe ich nicht, wieso Photoline während der Stapelverarbeitung nicht mehr reagiert. Intern läuft ja etwas in der Art wie die Aktion bei dem Webexport ab. Hier geht das völlig ohne Bildschirmausgabe, das Hauptfenster wird auch neu gezeichnet, wenn der Webexport offen ist.

Falls die Stapelverarbeitung also in dieser Art arbeitet muss lediglich der erneute Aufruf unterbunden werden (ist code reintrant?) - alle anderen Funktionen könnten weiter bestehen bleiben und würden - verlangsamt - funktionieren, wenn während der Verarbeitung immer wieder mal, die messageloop, also PeekMessage(Msg, 0, 0, 0, PM_REMOVE) (unter windows) aufgerufen wird.

Ich würde aber vorschlagen zu Begin des Prozesses eine Liste mit den zu bearbeiten Bilder anzulegen, die kann man dann noch für einen Fortschrittsbalken verwenden. Wenn man das so macht, ist auch ein Wechseln des Verzeichnisses im Browser unschädlich.

Am schönsten wäre dies natürlich in einem seperaten Task. Eine einfache und stabile Lösung wäre der Aufruf einer separaten EXE welche über die Kommandozeile die Aktion, die Dateiliste und die Ausgabe Parameter bekommt. Diese Exe würde dann in einem weiteren Prozess, auf anderer CPU, völlig ungestört im Hintergrund laufen. Ein kleines "stay on top" Fenster könnte über den Fortschritt informieren. Ob der code reintrant ist spielt dann auch keine Rolle mehr.

Ich würde mir aber einen Pause / Abbrechen Button auf dem Dialog wünschen. Gerade bei solchen Prozessen ist es praktisch sie mal anzuhalten, wenn man den Rechner zwischendrin benutzen möchte. Der Kommandozeilenaufruf in dieser Art wäre auch sonst ein richtiges Highlight. (träum)

Grüsse,
Julian

User avatar
Hoogo
Betatester
Posts: 3860
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Statusbalken bei Stapelverarbeitung

Post by Hoogo » Tue 13 Oct 2009 16:15

Hach, da träumt noch jemand vom Coding... :D

User avatar
NoSi
Betatester
Posts: 984
Joined: Mon 07 Jan 2008 19:52
Location: Braunschweig

Re: Statusbalken bei Stapelverarbeitung

Post by NoSi » Tue 13 Oct 2009 16:30

Hi.

Ich glaube, ich verstehe langsam, was Hoogo wirklich gemeint hat... .

Also ich will mit Photoline schöne Bilder machen. Die Programme, die schöne Bildschirme machen, habe ich mittlerweile alle in die Tonne getreten. Solche hanebüchenen Sachen, einen Screenshot neu zu zeichnen (ich kenne diverse Programme, die zeigen zwar einen Schirm, sind im Taskmanager aber trotzdem tot, - meinst du solche??), etc. - was für eine Welle ohne einen Nutzen! Wenn ich mich nicht mehr erinnern könnte, dass ich dem Programm einen heftigen Job aufgedrückt habe und mich nicht drüber freuen könnte, dass es dem Programm wichtiger ist, den zu erledigen, statt sich mit nutzlosem Aufzuhalten, dann hätte ich keine Sorgen mehr, weil das ist so ziemlich das unwesentlichste, was mich - wenn überhaupt - an einem Programm stören könnte. Da ich das mit dem weißen Schirm problemlos auch mit Photoshop hinbekomme, oder - wie oben erwähnt - mit praktisch jedem Programm, würde ich das nicht als Problem von Photoline sehen, sondern eher als Problem des Betriebssystems, dass es das nicht cachen kann. Aber bei Microsoft kann man so ein Probleme zwar abwerfen, aber es diskutiert keiner mit. Warum wohl?

Grüße
NoSi
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer und ausschließlich die aktuellste Beta-Version.

JulianZI
Mitglied
Posts: 711
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Statusbalken bei Stapelverarbeitung

Post by JulianZI » Tue 13 Oct 2009 16:51

Norbert,

hanebüchen ist das sicher nicht. Es nennt sich Doublebuffering und ist ziemlich Standard in allen Programmen, welche sich nicht durch Flackern während der Arbeit auszeichnen. Evtl arbeitet auch Photoline so. "Screenshot" ist letztendlich nur eine Umschreibung dafür, im übrigen aber ein Woraround, falls das Programm von Haus aus nicht Doublebuffering verwendet. Dann verwendet man einfach einen BitBlt( fenster_dc, ..., bitmap_dc ) und fertig ist die Bitmap. Diese bitmap neuzuzeichnen geht nicht nur viel schneller als die Ausgabe der dafür notwendigen Sachen, es kann auch von den ursprünglichen Daten unabhängig erfolgen. Wichtig, falls die Daten gerade anderweitig verwendet werden.
Ganz ehrlich - hanebüchen ist eher die Greschichte von "mit vollem Munde essen" :)
Die Programme, die schöne Bildschirme machen, habe ich mittlerweile alle in die Tonne getreten.
Photoline würde nicht schlechter, wenn man an der Oberfläche etwas Feinschliff macht. Viel Zeit braucht das sicher auch nicht. Eine seperate EXE bzw Prozess sollte auch kein Hexenwerk sein. Ich denke Photoline ist schon von Hausaus gescriptet genug, das sowas ziemlich schnell klappen sollte.

Jedes Programm stürzt mal ab und ist dann tot. Darum gehts hier aber nicht. Dafür gibts ja den Taskmanager.

Grüsse,
Julian

User avatar
Hoogo
Betatester
Posts: 3860
Joined: Sun 03 Jul 2005 13:35
Location: Mülheim/Ruhr

Re: Statusbalken bei Stapelverarbeitung

Post by Hoogo » Tue 13 Oct 2009 17:09

Äh, ja, kann sein, daß ich das meinte... :shock:

Ich programmiere nur VB, da sind die meisten technischen Dinge vor mir verborgen. Aber Bildschirm aktualisieren oder gar auf Klicks reagieren kann ein Programm nur, wenn es nicht gerade beschäftigt ist oder sich freiwillig mal Gelegenheit für die kleinen Aufgaben zwischendurch nimmt, was dann aber wieder fiese Nebeneffekte haben und tatsächlich furchtbar viel Zeit fressen kann. Weiße Bildschirme sehe ich am laufenden Band, nicht nur bei eigenen Klicki-VB-Programmen, bei z.B. Opera oder Access sehe ich das auch öfters, ist einfach so...

Persönlich finde ich zwar ein ständig reagierendes Programm auch "hübscher", aber ein schnelles Programm ist mir doch lieber, drum pfeiff ich bei eigenen Programmen auf den weißen Bildschirm.

JulianZI
Mitglied
Posts: 711
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Statusbalken bei Stapelverarbeitung

Post by JulianZI » Tue 13 Oct 2009 17:22

Hallo Hoogo,

bei VB hast Du in der Tat keinen Zugriff auf die Nachrichtenschleife. In C, Delphi etc geht dies aber. Hier ist es auch möglich die Nachrichten aus der Nachrichtenschleife (Messageloop) selektiv abzuholen, also z.b. nur den Bildschirm zu zeichnen (WM_PAINT) und die anderen Nachrichten in der Schleife lassen. Mit der aufgezeichneten Technik ist es schon möglich entweder den vorherigen Bildschirm oder was anderes während der Arbeit anzuzeigen.

Allerdings muss während der Arbeit in die Nachrichtenschleife reingeschaut werden. Das passiert im Moment nicht. Die Taste ESC wird wohl über GetAsyncKeyState abgefragt, was an der Schleife vorbeigeht.

Wenn man aber möchte, daß sich ein Fenster neuzeichnet, ohne dass die Nachrichtenschleife abgearbeitet wird, kann man auch die Fensterfunktion mit der WM_PAINT message direkt aufrufen. Damit wird also das Fenster gezeichnet, im übrigen reagiert das Programm aber nicht. Ich finde diese Methode aber nicht gut, da sie einen nicht weiter bringt.

Es ist auch nicht mehr Standard, dass ein Programm längere Zeit nicht reagiert. Für derartige Programme generiert Windows XP schon mal eine Warnung "Programm reagiert nicht - Beenden?".
Gerade wegen der super tollen Stapelbearbeitung, finde ich esc schon schade, daß PL32 sich während der Arbeit etwas unkomunikativ verhält.

Grüsse,
Julian

User avatar
NoSi
Betatester
Posts: 984
Joined: Mon 07 Jan 2008 19:52
Location: Braunschweig

Re: Statusbalken bei Stapelverarbeitung

Post by NoSi » Thu 15 Oct 2009 08:43

@Julian:

Doublebuffering ist was ganz anderes als ein „Screenshot“. Es ist - genau genommen - das Gegenteil davon. Dabei wird der Bildschirm nicht linear gezeichnet, sondern verdeckt in einen „Buffer“, der dann per „BitBlt“ in den Bilschirmbuffer geschrieben wird. Damit wird Flackern beim schieben großer Objekte über den Schirm verhindert. Ich bin sicher, dass diese Funktion in PL aktiv ist. Sie wird vom Betriebssystem bereitgestellt, darauf hat PL keinen Einfluss. Man kann damit lediglich entscheiden, ob die eigenen Inhalte direkt oder über den Buffer auf den Schirm kommen. Allerdings bleibt der Bildschirm trotz Doublebuffer leer, wenn nichts in den verdeckten Buffer geschrieben wird.

Deine Problematik mit dem „weißen Fenster“ lässt sich darüber hinaus gar nicht allein an PL festmachen. Wenn Du das Fenster verkleinert hast, arbeitest Du parallel an etwas anderem – warum sonst solltest du das Fenster verkleinern. In wieweit beim Fensterwechsel PL die Probleme hat oder Programme, „von denen Du kommst“ lässt Du völlig unbeleuchtet. Ich arbeite beispielsweise z.Z. an einem Videoprojekt. Wenn das Schnittprogramm aktiv ist, werden alle anderen Programme, die sonst reibungslos miteinander funktionieren, träge wie ein Faultier. Auch PL. Ob da dann noch Zeit für „aufrüschen“ investiert wird, spielt dabei keine Rolle, denn wenn andere Programme einfach keine Ressourcen freigeben, bringt das nichts. Es dauert nur noch länger.

Wenn Du mit dem Taskmanager argumentierst, kannst du da ebenso gut nachsehen, ob PL noch werkelt.Im Vergleich zu anderen Produkten hält sich PL imho mehr als wacker. Ich kenne diverse Programme, die zeigen mir zwar einen Dialog mit Fortschrittsbalken, der rührt sich aber nicht oder derart schwachsinnig (1sec: 1 Segment - 60 sec nichts - dann, flutsch, die restlichen 99%), dass ich das nicht als „Feinschliff“ bezeichnen würde.

Was Deine Ausführungen zu WM_PAINT betrifft: Der Bildschirm wird nur neu gezeichnet, wenn Du (z.B. in Delphi) mit „ProcessMessages“ die Erlaubnis dafür gibst. Damit lässt Du aber alle anstehenden Nachrichten durch, d.h. alle – auch „die anderen – kommen erst mal dran. Du kannst natürlich in den Systemeigenschaften - Erweitert - Leistungsoptionen - Erweitert die Hintergrunddienste favorisieren. Dann wird auch mehr auf dem Bildschirm gemalt, weil dann erzwingt Windows Päuschen für die eigenen Bedürfnisse.

Was Dein Kommunikationsbedürfnis betrifft, will ich es mal ganz plastisch formulieren: Mich würde es ziemlich nerven, wenn ich bei einer Rechenaufgabe ständig zum Pläsier für die Umstehenden rufen sollte: „Ich rechne noch!“ bis ich die Aufgabe gelöst habe. Insbesondere, wenn ich mir hinterher womöglich anhören muss, ich hätte mir ganz schön Zeit gelassen.

Grüße
NoSi
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer und ausschließlich die aktuellste Beta-Version.

JulianZI
Mitglied
Posts: 711
Joined: Tue 19 Dec 2006 19:54
Location: München

Re: Statusbalken bei Stapelverarbeitung

Post by JulianZI » Thu 15 Oct 2009 09:39

Danke, daß Du auf meine Ausführung eingehts,

In meinen Applikationen hebe ich den Doublebuffer auf, solange die Anwendung keine anderen Daten ausgeben muss (oder darf!). Wenn also ein Fenster mein Arbeitsfenster verdeckt und dann verschoben wird, erstelle ich die Anzeige aus dem Doublebuffer. Dabei ist es zum einen völlig egal, ob die Daten gerade nicht verfügbar sind, da sie z.b. gerade für eine andere Ausgabe (druck) gebraucht werden, zum anderen geht dies natürlich auch sehr schnell. Auf diese Technik hatte ich angesprochen.

ProzessMessages ist mir selbstverständlich bekannt, auch die Nebeneffekte. Intern arbeitet ProzessMessages aber lediglich mit einem PeekMessage ohne Filter. Es ist durchaus möglich hier einen Filter zu verwenden "und nur die guten" messages sich anzusehen. Oder man schaltet die Neuberechnung des Doublebuffers eben ab. Was hier nötig ist, hängt von den Interna der Mehrfachkonvertierung ab. Mindestens erforderlich dürfte sein, keine weitere Mehrfachkonvertierung zu starten. Für X Minuten gar keine Messages mehr zu verarbeiten ist eigentlich nicht mehr erlaubt und wird, wie schon gesagt, von Windows zumindest durchaus als Absturz interpretiert.

Daß ein Programm den Rechner zum Stehen bringen bringt kannte ich von früher. Seit Dual Code ist das ganz selten geworden. Lightroom z.b. ist sehr wohl in der Lage 1000 Bilder im Hintergrund zu entwickeln, ohne daß Fenster weiß werden oder sich nicht mehr verschieben lassen. Bei einer Video Kodierung oder auch Brennsoftware sehe ich ja ein, daß alle Resource gebraucht werden, beim einem Batchjob aber nicht.

Das alles spielt aber keine Rolle wenn die Mehrfachkonvertierung in einen anderen Prozess ausgelagert wird. Es kann dieselbe EXE sein, mit speziellem Aufrufparameter (vielleicht einer skriptdatei) welche intern lediglich Ihre Instanzerkennung abschalten muss. Dies braucht dann auch kein Hauptfenster mehr sondern nur einen Dialog. Ich finde dies keinen abwegigen Vorschlag und sehr viel leichter zu realisieren als multithreading. Ausserdem hat man dann noch Kontrolle über den anderen Prozess und ein Hängen bringt das Hauptprogramm nicht um. Weitere CPUs werden automatisch benutzt.
Mich würde es ziemlich nerven, wenn ich bei einer Rechenaufgabe ständig zum Pläsier für die Umstehenden rufen sollte: „Ich rechne noch!“ bis ich die Aufgabe gelöst habe. Insbesondere, wenn ich mir hinterher womöglich anhören muss, ich hätte mir ganz schön Zeit gelassen.
Na, zum Glück rufen die Anwendungen ja nicht. Übrlich ist die Angabe eines Prozentwertes, z.b. bei einem verkleinerten Fenster in der Taskbar.
Der Nutzen für den Anwender - er weiss wie lange es noch dauert und daß es tatsächlich mal fertig wird.

Die Anzeige wird auf jeden Fall die Arbeit nicht nenneswert verlängern - solche Ausgaben oder auch Bildschirmwiederhestellung braucht vielleicht ein paar mms.

Ansonsten finde ich die Mehrfachkonvertierug (mit Aktion) eine der ganz großen Features in Photoline.

User avatar
NoSi
Betatester
Posts: 984
Joined: Mon 07 Jan 2008 19:52
Location: Braunschweig

Re: Statusbalken bei Stapelverarbeitung

Post by NoSi » Mon 19 Oct 2009 10:29

JulianZI wrote:[...]Lightroom z.b. ist sehr wohl in der Lage 1000 Bilder im Hintergrund zu entwickeln, ohne daß Fenster weiß werden oder sich nicht mehr verschieben lassen. Bei einer Video Kodierung oder auch Brennsoftware sehe ich ja ein, daß alle Resource gebraucht werden, beim einem Batchjob aber nicht. [...]
  1. Wenn eine Application alle Ressourcen ziehen kann, damit sie nicht weiß wird, brauche ich kein Multitasking, weil dann für die anderen Apps keine Power mehr da ist.
  2. Warum eine Videoapplikation das Recht haben sollte, alle Energie an sich zu reißen, eine Grafik-Applikation aber nicht, vermag sich mir nicht recht zu erschließen.
  3. Man kann sich - wenn man sonst nichts zu tun hat - eine Menge Arbeit für Belanglosigkeiten machen.
  4. Jeder zusätzliche Code kann Probleme verursachen. Insbesondere, wenn man sich ins Taskmanagement reinhängt. Für ein bisschen optisches Tuning ein wie von dir vorgeschlagenes Buhei ohne Nutzen für das gewünschte Resultat (Batch von Bildern, gutes Antwortverhalten weiterer Applikationen), würde ich den Hubers schwer ankreiden, weil dafür andere Dinge, die wirklich wichtig/nützlich sind, liegen bleiben würden.
  5. Ich gehe als Anwender grundsätzlich davon aus, dass eine Anwendung mal fertig wird, selbst wenn sie mir nichts erzählt. Das ist bei mir in 99,9% der Fälle kein Absturz sondern einfach "normal", denn ich kann mir gerade noch so merken, dass ich einer Anwendung "ordentlich Arbeit" gegeben habe.
  6. Auch ein Fortschrittsbalken kann stehen (bzw. tut er in diversen mir bekannten Grafik-Apps) - kann ich wirklich daran erkennen, dass eine Anwendung nicht oder doch abgestürzt ist?
  7. Ein Balken, der sich (mal kurz) nicht bewegt, löst beim Anwender eher das Gefühl eines Fehlers aus, als ein Fenster, das nicht neu gezeichnet wird. Dafür wird eher Verständnis entwickelt (oh, arbeitet!) als wenn eine Tätigkeitsanzeige (scheinbare) Untätigkeit anzeigt (aus diesem Grund habe ich aus einem Datenbank-Konverter einen Fortschrittsbalken wieder raus genommen, weil die Anwender meinten, er sei abgestürzt, mit der Meldung "das kann dauern..." waren sie dagegen zufrieden. Auffällig: diese Strategie ist in immer mehr Anwendungen anzutreffen, bei denen zeitlich nicht bestimmbare, längere Prozesse anfallen).
  8. Wie lange es dauert, sagt mir eine Anwendung mit einem Balken nicht ansatzweise, denn ein Balken, irgendwo zwischen 0 und 100% ist völlig bezugslos zur relevanten Größe "Zeit".
Grüße
NoSi
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer und ausschließlich die aktuellste Beta-Version.

marduk4all
Mitglied
Posts: 132
Joined: Mon 02 Feb 2009 23:26

Re: Statusbalken bei Stapelverarbeitung

Post by marduk4all » Mon 19 Oct 2009 11:42

zu 1: Mag sein.
zu 2: Ich kenne keine Videoapplikation bei der man während einer Verarbeitung nicht weiß welches Frame grade bearbeitet wird und wie lange es noch dauern wird.
zu 3: Das ist deine persönliche Meinung.
zu 4: Wenn sich ein Prgramm tot stellt, sich nicht mehr maximieren und abbrechen lässt, sind bereits Fehler im Code vorhanden.
zu 5: Das ist deine persönliche Meinung.
zu 6: Es gibt auch andere Wege, siehe FastStoneImageViewer. Dort wird der Anwender vernüftig infomiert und wenn es 10% länger dauert ist das mir persönlich egal. Bahnbrechend schneller ist PhotoLine jedenfalls nicht.
zu 7: Das ist deine persönliche Meinung.
zu 8: siehe Punkt 6

akeller
Mitglied
Posts: 1000
Joined: Fri 03 Apr 2009 19:10

Re: Statusbalken bei Stapelverarbeitung

Post by akeller » Mon 19 Oct 2009 22:10

*
Last edited by akeller on Thu 28 Oct 2010 20:47, edited 1 time in total.

User avatar
NoSi
Betatester
Posts: 984
Joined: Mon 07 Jan 2008 19:52
Location: Braunschweig

Re: Statusbalken bei Stapelverarbeitung

Post by NoSi » Mon 26 Oct 2009 12:04

marduk4all wrote:zu 2: Ich kenne keine Videoapplikation bei der man während einer Verarbeitung nicht weiß welches Frame grade bearbeitet wird und wie lange es noch dauern wird.
Magix Video de Luxe, Pinnacle Studio, Adobe Premiere, ... - die haben zwar alle einen Balken beim Export, aber der sagt schlicht gar nichts und sie sind unbedienbar und sie machen - wenn überhaupt - nur einen zähen Redraw, der - wirklich fatal - andere Programme ausbremst, bzw. zum Stehen bringt.

Beispiel Magix. Da wird ein Balken gemalt und ständig eine Zeit "wie lange noch" angezeigt, aber die ändert sich nicht, bzw. hat mit dem, was es wirklich "kostet" nicht ansatzweise etwas zu tun. Die "10%" liegen schon mal um 1000 - 4000% daneben (ich habe aus Neugier mal einen externen Timer mitlaufen lassen...). Das ist "Augenwischerei" die ich - ja das ist meine persönliche Meinung (dein Standpunkt ist doch auch "persönlich", oder?) - für Unfug halte. Wenn man nicht weiß, wie lange etwas dauern wird (das ist insbesondere bei Batch-Aktionen der Fall, die der Anwender selbst zusammengeschraubt hat) ist es schlicht ehrlicher, gar nichts zu sagen, als ständig was Falsches oder die Unwahrheit rauszutröten und dafür noch Ressourcen zu verschwenden. Das ist sowas wie ein Schattenhaushalt, damit man die Neuverschuldungsregel des Grundgesetzes einhält ... .

Grüße
NoSi
Screencasts zu Photoline: http://www.buoa.de • Win 10x64 / PL64, immer und ausschließlich die aktuellste Beta-Version.