Bekommen GUI Anwendungen die gerade nicht benutzt werden, vom OS einen Zeitschlitz?

Oder liegen die derart völlig brach, dass sie auch keinen Zeitschlitz vom OS zur Verfügung gestellt bekommen, solange der Nutzer diese nicht aktiv auswählt.

Sind das dann überhaupt im Hintergrund laufende Prozesse und falls ja, benötigen sie dann Rechenzeit, wenn sie gerade nicht benutzt werden?

PS:
Es geht nicht um Anwendungen die im Hintergrund irgendwas berechnen (z.b. Video enkodieren), weil der Benutzer das so ausgewählt hat.
Sondern eher um so Anwendungen wie z.b. der Browser oder der Taschenrechner oder ein Editor. Kostet das also Rechenzeit, wenn Notepad minimiert wurde und gerade nicht das aktive Fenster ist, weil Notepad einen Cursor hat, der blinken soll?

Da Frage bezieht sich auf insbesnodere darauf, das Blinken mag nicht viel Rechenzeit kosten, aber ein Prozesswechsel ist teuer, wenn man dem beim gerade aktiven Prozess nicht gebrauchen kann.

Kommt natürlich auf das Programm an. Wenn es "runnable" ist, bekommt es auch Rechenzeit. Programme, die daran interessiert sind, den Akku des Benutzers zu schonen, legen sich deshalb schlafen und warten auf ein entsprechendes Ereignis.

In regelmäßigen Abständen irgendwelche Sinnlosaufgaben durchzuführen, die man besser interrupt-gesteuert machen könnte, ist jedenfalls nicht die feine Art. Solche Akkusäue würde ich von meinem System verbannen.

Viele Terminalemulatoren oder Texteditoren bieten daher die Möglichkeit das Blinken des Cursors zu deaktivieren oder haben das gleich als Defaulteinstellung.

Das obige gilt zumindest für gängige Desktop- und Serverbetriebssysteme. Android z.B. hat einige Kernel-Modifikationen, die Programme mit schlechten Manieren zwangsweise schlafen legen, wenn der Anwender sie nicht benutzt.

hustbaer

ert55 schrieb:

Kostet das also Rechenzeit, wenn Notepad minimiert wurde und gerade nicht das aktive Fenster ist, weil Notepad einen Cursor hat, der blinken soll?

Der Cursor blinkt doch immer nur in dem Fenster das gerade den Input-Fokus hat. Und ich würde mal davon ausgehen dass die entsprechenden Controls die das umsetzen schlau genug sind den Timer wirklich zu vernichten/stoppen wenn sie den Fokus verlieren.

Da Frage bezieht sich auf insbesnodere darauf, das Blinken mag nicht viel Rechenzeit kosten, aber ein Prozesswechsel ist teuer, wenn man dem beim gerade aktiven Prozess nicht gebrauchen kann.

Prozesswechsel hast du sowieso dauernd. Und einen zusätzlichen Prozesswechsel pro Sekunde, das merkst du nicht. Wenns mal 100+ sind vielleicht. Wären dann aber schon ne Menge Notepads.