Warum nicht einen Keil?

Ich habe vorhin einige Änderungen am Cube committed. Die Innenwinkel werden nun in Abhängigkeiten der verwendeten Arbeitsflächen errechnet und auch die Texturzugriffe werden errechnet. Dies gibt uns einige weitere Möglichkeiten: wir sind nicht mehr auf einen Würfel beschränkt. So kann man nun auch mit 3 Arbeitsflächen einen Keil erstellen:
Keil

Mehr als 4 Seiten funktioniert leider noch nicht. Bei 5 Seiten treffen sich die zwei hinteren Flächen noch nicht. Aber das wird schon 😉

Ach ja wie man im Screenshot sehen kann ist die Performance nicht gerade die Beste. Das muss ich auch noch in Griff bekommen. Ist aber gerade nicht Prio A nachdem ich am Samstag die FPS Rate vervier bis fünfacht habe.

Wir haben einen Würfel

Heute habe ich meinen bisherigen Stand meines Summer of Code Projektes in das SVN Repository hochgeladen. Wer sich dafür interessiert: ich habe einen Branch angelegt: branches/work/soc-kwin-cube.
Die Quellcode Dateien finden sich in effects/cube.h und effects/cube.cpp. Aktuell ist der Code natürlich noch nicht wirklich gut. So werden nur vier Arbeitsflächen unterstützt und Rotation funktioniert auch noch nicht. Trotzdem kann ich schon einen Screenshot präsentieren:
Wie man sieht werden bereits Fenster um die Ecken herumgeklappt. Das ich dies so früh schon zeigen kann, freut mich besonders.

Irgendwie macht es mich ja schon stolz…

… dass in der Release Note zur Beta 1 mein CoverSwitch Effekt benannt und bebildert ist. Und dass Golem auch einen Screenshot davon abgebildet hat. Vielen Dank sebas. Das ist das beste Feedback, das man einem neuen Entwickler geben kann.

Nun noch zu was Technischem: Im Golem Forum hab ich natürlich sofort einen Troll-Post gelesen, in dem sich darüber beschwert wurde, dass CoverSwitch kein Antialiasing verwendet. Eigentlich würde ich solche Posts ignorieren, aber es ist ja was dran. Natürlich wäre es kein Problem Antialiasing einzuschalten und natürlich hatte ich das auch ausprobiert. Jedoch führt das zu einigen Problemen:

  1. der Effekt soll alte Karten ja nicht außer Gefecht setzen. Leider gibt es keinen API Aufruf kannstDuBlendingSchnell(). Somit würden besonders alte Intel Karten bei vielen Fenstern nicht mehr in der Lage sein den Effekt darzustellen.
  2. Antialiasing würde auf alles angewendet – also auch auf Schrift und auf Farbverläufe (wovon es in Oxygen sehr viele gibt). Das führt dann natürlich dazu, dass dann alles wie verschwommen aussieht. Ich hätte das ganze jetzt natürlich gerne mit einem Screenshot bewiesen, jedoch weigert sich CoverSwitch die Fenster zu zeichnen, sobald ich Antialiasing einschalte. Das sind nur drei Zeilen Code und werden an anderen Stellen selbstverständlich verwendet.

Mein erstes KDE-Event

Heute hab ich zum ersten Mal die KDE auf einer Messe unterstützt und zwar auf der OpenExpo in Karlsruhe. Hat mir sehr gut gefallen, hat Spaß gemacht und ich konnte zum ersten Mal ein paar KDE/Amarok Leute kennen lernen 😉 Wirklich alle sehr nett.

Und so wie es läuft wurde man auch gleich ins kalte Wasser geschmissen und ich durfte beim Vortrag die Effekte von KWin vorführen.

Schade, dass ich morgen nicht noch einmal hingehen kann (letzte Vorlesung vor Klausur) und auch nicht auf den Linuxtag kann.

Da freut man sich schon auf das nächste Event 🙂

Updates on CoverSwitch

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:
CoverSwitch

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 😉

Was ist so besonders an diesem Post?

Der Eintrag ist in einem WebKit Browser geschrieben.
Ich habe dieses Wochenende mal die KDE 4.1 pre pre alpha (oder wie man so was nennt) gebaut und bin gerade in einer KDE 4.1 Session. Als kleine Zugabe hab ich auch mal den WebKit Part für Konqueror gebaut und ja er funktioniert 😉 Ein langer Wunsch geht in Erfüllung: WebKit Browser.

KDE 4.1 macht jetzt einen sehr guten Eindruck. Klar es ist noch eine Alpha und an ein paar Stellen harkts (Systray wird nicht neu gezeichnet), aber ich glaube ich werde es nun produktiv einsetzen. Das liegt aber eher daran, dass ich zum Bauen von KDE 4.1 Qt 4.4 benötige und das macht Plasma aus KDE 4.0 fast unbenutzbar.

Ich hab jetzt auch Amarok und Kontact in der KDE 4 Variante 😉

KBlogger

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 😉

Konqui ist tot – es lebe Konqui

Nach zwei Monaten schwerer Krankheit ist heute durch ein Upgrade auf Hardy Heron Alpha 6 KDE 3 auf meinem Rechner gestorben. Was sich bereits im Januar andeutete, konnte nun vollendet werden: der Nachfolger KDE 4 lebt und hat nur noch wenige Verweise auf die alte KDE 3 (amarok, kile, k3b, kdevelop, kaffeine, …). Und auch diese wenigen Überbleibsel werden wohl im nächsten halben Jahr sterben.

KDE 3 du warst ein guter Partner. Du hast mich zu Linux gebracht und mir den Anfang vereinfacht. Du hast tolle neue Software bekommen, die bei mir zum Standard wurden. So z.B. Kontact und kaffeine. Nun bist du aber in die Jahre gekommen. Viele deiner Teile waren kaum noch wartbar. So wurde ein Nachfolger für dich entwickelt. Dieser dein Sohn hat dir am 11. Januar eine tödliche Wunde versetzt. Du der ergraute König bist tot – es lebe der König.

TwinView sucks…

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.