Das neueste Pamphlet ist eher eine Antwort auf die zum Teil sehr schlechten Reaktionen der Nutzer auf die KDE 4.5.x-Veröffentlichung. Nach KDE 4.0 bis 4.2 waren KDE4-Nutzer mit KDE 4.3 und 4.4 ganz glücklich. Und jetzt geht dieses ganze Entwicklungsgefrickel, das schon leichte enlightenmentartige Züge trägt, schon wieder los (Akonadi und OpenGL2).
Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?
Das ist leider die Linux-Achillesferse schlechthin, nämlich die langsame Mesa-3D-Treiberentwicklung, die zur Zeit auch noch in zwei Entwicklungsstränge aufgesplittet ist, den Strang mit den klassischen Mesa3D/Dri-Treibern und den Gallium-Strang. Zur Zeit ist kaum etwas wirklich fertig, es fehlt vor allen Dingen an Entwicklern. Auch KDE4 und Gnome3 sollten dafür Verständnis aufbringen.
"Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?"
So ist es ja nicht. Einige Treiber sagen das die Funktion X oder Y können damit sie die OGL Version Z beherrschen obwohl sie es nicht können oder nur Fehlerhaft.
Der Grund ist das viele Programme nur nach der OGL Version fragen und nicht nach den Erweiterungen bzw. was die Karte alles kann.
So ist es ja nicht. Einige Treiber sagen das die Funktion X oder Y können damit sie die OGL Version Z beherrschen obwohl sie es nicht können oder nur Fehlerhaft.
Wird das tatsächlich mit Absicht gemacht? Gibt es dafür irgendwo Belege? In dem Fall könnten sich die kwin-Entwickler die ganzen Abfragen die sie momentan machen eigentlich auch gleich sparen.
Wenn man einen derartigen Workaround anbieten will, dann kann man das ja gerne in Anwesenheit einer Umgebungsvariable alla OPENGL_VERSION_HACK machen aber doch bitte nicht als Default.
Als Beispiel können die r100-r400 und NV30 kein GL_ARB_texture_non_power_of_two bzw nur eingeschränkt was aber ab der Version 2.0 vorgeschrieben ist. PS: Auch die Blobs von Nvidia und ATI Melden hier OGL 2.1
Das neueste Pamphlet ist eher eine Antwort auf die zum Teil sehr schlechten Reaktionen der Nutzer auf die KDE 4.5.x-Veröffentlichung.
Nach KDE 4.0 bis 4.2 waren KDE4-Nutzer mit KDE 4.3 und 4.4 ganz glücklich. Und jetzt geht dieses ganze Entwicklungsgefrickel, das schon leichte enlightenmentartige Züge trägt, schon wieder los (Akonadi und OpenGL2).
Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?
Das ist leider die Linux-Achillesferse schlechthin, nämlich die langsame Mesa-3D-Treiberentwicklung, die zur Zeit auch noch in zwei Entwicklungsstränge aufgesplittet ist, den Strang mit den klassischen Mesa3D/Dri-Treibern und den Gallium-Strang.
Zur Zeit ist kaum etwas wirklich fertig, es fehlt vor allen Dingen an Entwicklern.
Auch KDE4 und Gnome3 sollten dafür Verständnis aufbringen.
"Macht es denn für einen Desktop Sinn, mehr OpenGL-Features einbinden zu wollen als die freie Xorg-Grafikkartentreiberwelt zur Zeit an OpenGL-Funktionalität hergibt?"
So ist es ja nicht. Einige Treiber sagen das die Funktion X oder Y können damit sie die OGL Version Z beherrschen obwohl sie es nicht können oder nur Fehlerhaft.
Der Grund ist das viele Programme nur nach der OGL Version fragen und nicht nach den Erweiterungen bzw. was die Karte alles kann.
Wird das tatsächlich mit Absicht gemacht? Gibt es dafür irgendwo Belege? In dem Fall könnten sich die kwin-Entwickler die ganzen Abfragen die sie momentan machen eigentlich auch gleich sparen.
Wenn man einen derartigen Workaround anbieten will, dann kann man das ja gerne in Anwesenheit einer Umgebungsvariable alla OPENGL_VERSION_HACK machen aber doch bitte nicht als Default.
Als Beispiel können die r100-r400 und NV30 kein GL_ARB_texture_non_power_of_two bzw nur eingeschränkt was aber ab der Version 2.0 vorgeschrieben ist.
PS: Auch die Blobs von Nvidia und ATI Melden hier OGL 2.1