Martin's Blog

Es ist etwas Zeit vergangen seit meinem letzten Post – hatte einfach nichts zum Berichten.
Nun ich war diese Woche endlich wieder fleißig und habe die Probleme mit TwinView in meinem CoverSwitch Effekt behoben. Also auch die Nutzer von zwei Monitoren können nun endlich in den Genuss kommen 😉
In der Zwischenzeit hat auch der Präsident der KDE e.V. einen Blick auf meinen Effekt geworfen und gleich an der Stelle verbessert wo ich per Definition versage: Design. Er hat die Farbwahl bei der Spiegelung etwas verändert und das sieht wirklich gut aus 😉 Seht selbst:

Ach für alle Freunde von Eye-Candy: der Wobbly-Windows-Effekt wurde heute in das KDE Repository hochgeladen. Habe es vorhin ausprobiert und der Effekt ist echt sehr gelungen – ich merke keinen Unterschied zu Compiz 😉

Kubuntu KDE 4 Hardy Heron enthält KBlogger, ein Programm zum Erstellen von Blog Einträgen und zum Uploaden zum Blog. Diesen Eintrag schreibe ich gerade mit KBlogger zum Testen. Erster Eindruck ist sehr positiv. Ist zwar noch laut Beschreibung Alpha, aber es sollte das Leben mit meinem Blog einfacher machen 😉

Ich hab mich heute einem Bug gewidmet, der bei meinen Desktop Effekten mit TwinView auftritt. Das Problem ist, dass TwinView den Desktop erweitert. Also wenn man zwei Monitore mit 1280×1024 hat, wird daraus “ein” virtueller Monitor mit 2560×1024. Wenn man nun über die ganze Breite zeichnet und die Fenster nach der Mitte ausrichtet kann man sich denken was passiert 😉

Zu meiner Verteidigung: ich kenne halt die KDE API noch nicht so gut und wenn es in Qt eine Klasse gibt, die mir die Dimension des Desktops liefert, dann nimm ich die halt. Leider beachtet dies halt nicht TwinView.

Da ich nun einen neuen Monitor hab, kann ich das jetzt auch mal ausprobieren. Außerdem wurde ein Bug dafür geöffnet. Ich muss den Effekt so ändern, dass er nur auf einem Bildschirm erscheint. Also was macht man als guter Informatiker? Richtig, man schaut sich an wie es andere gelöst haben. Quellcode von PresentWindows angeschaut und einen Aufruf effects->clientArea(…) entdeckt, der ein QRect zurückliefert, also genau das was ich eigentlich brauche. Ein Blick in die API bestätigt sofort meinen Verdacht: ich hab es falsch gemacht und clientArea(…) ist der richtige Weg. Also schnell mal geändert, mich schon gefreut, dass es gar nicht so viel Arbeit war und: nichts.

OpenGL macht mir einen Strich durch die Rechnung. clientArea(…) liefert mir zwar nur die Geometrie eines Bildschirms, aber wenn ich in OpenGL die Perspektive (3D) aufspanne, geschieht das wieder über den gesamten Bildschirm. Schön jetzt hatte ich zwar nur noch 1280×1024, male aber mittig in die 2560×1024. Also alles noch nichts gebracht.

An dieser Stelle setzt das Martin Syndrom ein. Anstatt eine Pause zu machen und nachzudenken (und den einfachen Weg zu finden) fange ich an einen Workaround zu programmieren. Ich vergleiche die gesamte Auflösung mit der Auflösung eines Monitors. Wenn die unterschiedlich sind, dann läuft TwinView. Nun nehme ich also für die Perspektive die gesamte “virtuelle” Auflösung, verschiebe aber das Zeichnen in den linken oder rechten Bildschirm. Yeah: funktioniert.

So nun kommt TwinView ins Spiel: zwei Bildschirme nebeneinander ist ja logisch, aber TwinView kann mehr. Man kann auch Bildschirme übereinander anordnen (wer sich das ausgedacht hat?). Nun hier wird es interessant. Auf dem unteren Bildschirm ist alles in Ordnung. Nur auf dem oberen da gibt es Probleme. Mein CoverSwitch Effekt nutzt ja Spiegelung. Das ist natürlich nur eine Pseudospiegelung. Ich spiegel alle Fenster, male dann eine semi-transparente silberne Fläche drüber und male dann alle Fenster normal obendrüber. Das ergibt bei einem Monitor das Gefühl von Spiegelung. Hier hab ich mal wieder die Rechnung ohne TwinView gemacht: natürlich werden die gespiegelten Fenster nicht komplett dargestellt. Irgendwo werden sie an der unteren Bildschirmkante abgeschnitten. Was passiert wenn man nun einen zweiten Bildschirm darunter ausrichtet? Richtig, sie werden weitergezeichnet. Natürlich ohne die Spiegelungsfläche, weil ein bißchen gedacht hab ich ja schon und zeichne natürlich nur im sichtbaren Bereich. Der Test sah echt toll aus (vor allem da die Bildschirme nur virtuell untereinander angeordnet waren).

Hier beginne ich mein Hirn einzuschalten. Ich überlege mir, ich muss das irgendwie abschneiden. Also eine clipping plane einziehen. Beim Lesen der OpenGL Doku fällt mir dann endlich die Lösung ins Auge: Viewports. Ich definiere einfach nur einen Zeichenbereich. Nämlich den, den mir clientArea() liefert. Keine Überprüfung mehr bin ich links, rechts, oben oder unten. Einfach das Zeichnen auf einen Monitor einschränken. Also Workaround auskommentiert glViewport() eingebaut, ausprobiert und ja es funktioniert. Zumindest links und rechts. Oben und unten hatte ich keine Lust mehr. Jetzt gibt es nur noch eine alles entscheidende Frage, die morgen an die Mailinglinst geht: darf ich viewports überhaupt benutzen oder gibt es irgendwelche ungeahnten Komplikationen mit schlecht geschriebenen Grafikkartentreibern? Ich denke aber ja.

Fazit nach einem Tag mit TwinView (zweiter Monitor ist mittlerweile ausgeschaltet): das ist ein großer Müll. Beim Programmieren war es bedingt angenehm auf dem zweiten Monitor die API Referenz zu haben, aber ansonsten ist das nur ein Müll. Kaum etwas funktioniert so wie man es erwartet und wenn die Monitore nicht perfekt nebeneinander angeordnet sind, ist es einfach nur störend.