Ich bastle gerade an einem animierten Finder-Schreibtischhintergrund (bitte jetzt nicht fragen, wozu man das braucht - brauchen tut man das nicht wirklich). Dazu nehme ich ein screengroßes Borderless-Window mit Desktop-Windowlevel. Soweit kein Problem.

Dummerweise scheint der Finder (oder sonstwer) auf dieser Ebene die regelmäßigen Updates der Animation zu verhindern. Sprich: Es animiert nur an der Stelle, an der man gerade ein Desktop-Icon bewegt o.ä. Sämtliches Herumgefummel an den Fenstereigenschaften oder händisches Triggern bringt nichts: Das Fenster, das auf normaler Fensterebene fein animiert, steht dort unten still.

Einen Trick habe ich gefunden, um das Fenster doch zu einem regelmäßigen Update zu überreden: Mit jedem Update ändere ich den frame origin des Fensters minimal (und gleich wieder zurück). Damit läuft es (fast gänzlich ohne Artefakte).

Allerdings finde ich diese Lösung nicht wirklich elegant. Hat jemand von Euch eine bessere Idee?

Danke Euch!

Original von zermelo
Haben sowas nicht schon einige Leute erfolgreich umgesetzt? Ich bilde mir ganz fest ein, dass es da sogar mal Sample Code gab. Ich glaube irgendwas mit einer Erdansicht, die immer aktuell ist. Oder so.

Wenn ja, wäre das toll. Hast Du zufällig irgendwo noch einen Verweis darauf? Ich konnte - trotz einigen Suchens - kein brauchbares Beispiel finden.

Original von Amin Negm-Awad
Wie hast du denn die Animation implementiert. Über die Event-Loop?

Jepp, stinknormaler Timer in der Main Event Loop. Ich kann mir aber nicht vorstellen, dass es daran liegt, denn auf anderen Windowlevels läuft es einwandfrei. Der Desktop-Level scheint in einigen Belangen anders gehandhabt zu werden (z.B. wird er von Exposé nicht zur Seite geschoben, was ja auch einen gewissen Sinn ergibt). Oder hast Du eine Idee, wie das mit dem Timer zusammenhängen kann?

Original von Apfelbeisser
So was hat Apple sogar fertig gebastelt:

Stimmt - das ist in der Tat eine elegantere Lösung, zumal mein View zufällig auch ein ScreenSaverView ist. Dummerweise hilft es mir nur wenig, herauszubekommen, wie das Ganze funktioniert (was ich zugegebenermaßen auch nicht gefragt hatte).

Original von Amin Negm-Awad
Richtig schön wie gedacht, kann ich mir das auch nicht denken. Setzt es doch mal testweise in den Common-Mode. (So hieß das Dingens für das Hintergrundrauschen doch!?)

Bin jetzt endlich dazu gekommen, das mal auszuprobieren. Scheint was anderes zu sein, Timer läuft fein. Trotzdem gut, das ausschließen zu können.

Original von ZermeloWas aber sicherlich sehr interessant sein sollte für dich ist GeekTool.

Guter Tipp, danke. Bei denen läuft's einfach so (die fummeln zwar wild in GCSPrivate rum, aber nur an einer anderen Stelle). Das hat mich eine Ecke weitergebracht: Das Problem taucht nur bei OpenGLauf Desktop-Level auf. Warum das so ist, weiß ich zwar immer noch nicht, aber immerhin bin ich einen Schritt weiter.

Anbei ein Sample, das das Problem illustriert - je ein OpenGL-View (gelb) und ein normal animierter View (weiß) auf Dokumentfensterebene und auf Desktop-Ebene. 3 von 4 Views laufen, der OpenGL-View auf Desktopebene steht. 10.5 und 10.6. Komisch.

Original von chartus
hm könnte das eine "optimierung" von apple sein?

Schätze ich auch. Aber vermutlich eine andere als die, die Du hast - Dein Phänomen kling ganz nach Coalesced Updates. Apple drosselt schon seit 10.4 standardmäßig die Refreshrate auf die Bildschirmrate, was ja auch recht sinnvoll ist. Viuelleicht haben sie mit 10.6 noch etwas an dem Mechanismus geschraubt. Man kann das grundsätzlich abschalten, aber ist das sinnvoll? Lieber die Animation fps-unabhängig implementieren und im Loop saubere Zeiten nehmen, oder?