Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?

[Ein ehemaliger Benutzer]

Du keine Ahnung ob das überhaupt noch jemand gerne sehen würde, so eine Einheits-GUI in OpenGL. Warum Hardwarbeschleunigte GUI? Nun weil die CPU entlastet wird, gibt ja auch sehr aufwändige visuelles Feedback und OpenGL ist mittlerweile auch auf Kleinstrechner wie Android oder RaspPI vorhanden, also nutzen.
Ich schreibe derzeit nur Software für mich selbst. Also solche Sachen. die ich gern von anderen Firmen sehen würde, die es aber so nicht gibt. Ob dann mal was für die Allgemeinheit daraus wird, das wird sich zeigen, ist aber nicht mein primäres Ziel.

Als ich auf der Suche nach einem GUI-Framwork war, habe ich mich an Blender erinnert und mich halt gefragt ob es so was nicht so in der Art von Qt gibt. Gibt es leider nicht, ein paar Ansätze habe ich gefunden wie CEGUI aber so richtig gefallen tut mir da nix. Deswegen meine Frage hier ob es so etwas in der Richtung noch gibt. Dass nicht jeder einen Sinn hinter meiner Suche sehen wird, ist mir schon klar.

[Swordfish]

@chris4cpp sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

gibt ja auch sehr aufwändige visuelles Feedback

Ja ne. Pixel rauswerfen tut inzwischen jeder Grafikchip im Schlaf und nebenbei.

[SeppJ]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@chris4cpp sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

gibt ja auch sehr aufwändige visuelles Feedback

Ja ne. Pixel rauswerfen tut inzwischen jeder Grafikchip im Schlaf und nebenbei.

Ähh, du weißt aber schon, dass man GUIs trotzdem mit OpenGL & Co. zeichnet? Warum sollte man nicht? OpenGL ist schließlich erst einmal ganz neutral ein Grafikframework und meistens bekommt man am Ende noch vom Grafiktreiber die Hardwarebeschleunigung geschenkt. Niemand setzt einzelne Pixel. Und wenn man Pixel setzt, dann wird das Pixelsetzframework intern auch OpenGL oder ähnliches nutzen, um sie an den Grafiktreiber zu bringen.

[Swordfish]

@SeppJ Ähm. Ja. Aber das würde bedeuten daß GUI malen aufwändiger ist als $Arbeit.

[SeppJ]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@SeppJ Ähm. Ja. Aber das würde bedeuten daß GUI malen aufwändiger ist als $Arbeit.

Häh?

[Swordfish]

@SeppJ Naja, wenn GUI malen aufwändiger ist als eigentliche Arbeit dann was falsch.

[SeppJ]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@SeppJ Naja, wenn GUI malen aufwändiger ist als eigentliche Arbeit dann was falsch.

Wiederholung macht weder deine Aussage, noch worauf sie sich bezieht, klarer. Aber soll mir egal sein. Wie die zeitgenössischen GUI-Grafikstacks aufgebaut sind, können du und chris4cpp selber nachschauen. Jedenfalls hat chris4cpp nicht unrecht, es kommt OpenGL (oder DirectX, etc.) irgendwo tief unten drin vor. Windowsbeschleunigerkarten wie Anno 1993 gibt es nicht mehr.

[Swordfish]

@SeppJ Ich weiß nicht wie ich das klarer ausdrücken soll. Aber wenn GUI-Darstellung zu lahm ist dann ist was anderes falsch und nicht das Knöpfchenmalen.

[SeppJ]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@SeppJ Ich weiß nicht wie ich das klarer ausdrücken soll. Aber wenn GUI-Darstellung zu lahm ist dann ist was anderes falsch und nicht das Knöpfchenmalen.

Indem du das so sagst
Da haste Recht, aber es gibt natürlich trotzdem keinen Grund, nicht die GPU-Beschleunigung zu nutzen, die man quasi geschenkt bekommt. Tatsächlich müsste man sich ja sogar ganz schön anstrengen, die GPU im Rechner zu umgehen, wenn man irgendetwas malen möchte.

[Swordfish]

@SeppJ sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@SeppJ Ich weiß nicht wie ich das klarer ausdrücken soll. Aber wenn GUI-Darstellung zu lahm ist dann ist was anderes falsch und nicht das Knöpfchenmalen.

Indem du das so sagst

^^

Jedenfalls hat chris4cpp nicht unrecht, es kommt OpenGL (oder DirectX, etc.) irgendwo tief unten drin vor.

Ja ne. Aber das heißt nicht daß man sich selbst die Finger schmutzig machen muss.

[SeppJ]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@SeppJ sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@SeppJ Ich weiß nicht wie ich das klarer ausdrücken soll. Aber wenn GUI-Darstellung zu lahm ist dann ist was anderes falsch und nicht das Knöpfchenmalen.

Indem du das so sagst

^^

Jedenfalls hat chris4cpp nicht unrecht, es kommt OpenGL (oder DirectX, etc.) irgendwo tief unten drin vor.

Ja ne. Aber das heißt nicht daß man sich selbst die Finger schmutzig machen muss.

Korrekt. Dann gucken wir zur Belehrung aller Leser vielleicht doch einmal den Stack eines üblichen Linux-Desktops an:

1. GTK+ (oder anderes GUI-Framework)
2. Cairo (oder andere 2D-Zeichenbibliothek)
3. OpenGL (oder anderes Renderframework)
4. X-Server (kann evtl. vom OpenGL-Renderkontext umgangen werden)
5. Grafiktreiber im Kernel
6. Hardware

Natürlich etwas vereinfacht, da es außer dem Renderkontext auch noch mehr Möglichkeiten zur Direktverbindung von Schichten gibt.

Aber ja, wir lernen, chris4cpp sucht so etwas wie cairo und sollte diesem überlassen, das Renderframework zu steuern.

PS: Viele Spiele und ähnliches zeichnen ihre GUI natürlich direkt mit OpenGL & Co.
Schließlich können sie sich darauf verlassen, dass es vorhanden ist, und sie sprechen sowieso schon direkt mit dem Renderframework. Insofern wäre dort eine Zwischenschicht nur unnötiger Mehraufwand.

[Swordfish]

@SeppJ sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

sollte diesem überlassen, das Renderframework zu steuern.

@SeppJ sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

Viele Spiele und ähnliches zeichnen ihre GUI natürlich direkt mit OpenGL & Co.

Dabei geht es aber seltenst um Effizienz sondern um eye candy. Ja, i know that You know.

[Ein ehemaliger Benutzer]

Ich denke schon, dass es bei der Spielentwicklung um jedes Tröpfchen Effizienz geht. Genauso wie bei der Entwicklung von Grafikappilikationen oder Software Synthesizer und DAWs. Dort das teilweise extreme Echtzeitfeedback mit Gradienten, Transparenz etc. per CPU zeichnen zu lassen wäre extrem ineffizient in meinen Augen. Klar kann man alles bestimmt auch mit einem 2D Software Renderer hinbekommen, aber wozu Ressourcen brach liegen lassen? Mittlerweile hat wirklich jeder SoC eine GPU die irgendwie mindestens OpenGL ES versteht. Also nutzen was eh schon da ist.

[Swordfish]

@chris4cpp CPUs zeichnen nichts (heute zumindest nimmer).

@SeppJ sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

Tatsächlich müsste man sich ja sogar ganz schön anstrengen, die GPU im Rechner zu umgehen

das da.

Heck, Windows 10 ist ohne mindestens DX9 garnicht supported.

Zu Faul zum Abtippen

[SeppJ]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

Zu Faul zum Abtippen

Für Leute, die nur das Bild angucken: GDI(+) ist nur noch wegen der heiligen Abwärtskompatibilität in Windows. Microsoft empfiehlt, heutzutage nur die rechte Hälfte des Bildes zu nutzen.

[Ein ehemaliger Benutzer]

@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

@chris4cpp CPUs zeichnen nichts (heute zumindest nimmer).

Alles was nicht OpenGL/DX etc, also GPU ist, wird von der CPU gezeichnet(Software Rendering). Aktuell zeichne ich noch mit der CPU und schiebe das Ergebnis als Bild an ein QLabel. Mit Zechenfunktionen von Qt selbst war das recht langsam, per Hand in einen Framebuffer schreiben ging wesentlich schneller. Aber das ist erst mal nur eine Krücke für die Echtzeitdarstellung der Soundbufffers, später soll die GPU vieles übernehmen. Meine Echtzeitwidgets in der GUI werden alle 40ms aktualisiert und das soll in etwa auch so bleiben. Jeder kleinste Geschwindigkeitsbonus zählt da für mich und daher auch mein Wunsch nach einer GPU GUI und das am liebsten mit 1:1 Look egal auf welcher Plattform. Denn dann wäre ich save und mir kann es egal sein wenn ein OS mal wieder seine Widgets ändert.

[Swordfish]

@SeppJ sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

Microsoft empfiehlt, heutzutage nur die rechte Hälfte des Bildes zu nutzen.

Das verschwendet ja die Hälfte vom Display!? *scnr*

@chris4cpp sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

Aktuell zeichne ich noch mit der CPU

Deine CPU zeichnet garnichts. Das war mal so. In einem fernen Land vor langer Zeit als man noch nach 0xb8000 geschrieben hat um was auf den Bildschirm zu bekommen. Du verwechselst da was. Wie Du Deine Pixelsammlungen zusammenbaust ist Dein Bier. Wie die auf den Bildschirm kommen ist OS/Graphics Driver-Bier.

[Ein ehemaliger Benutzer]

Natürlich zeichnet meine CPU in den Speicher. Dieser Bereich wird dann auf den Bildschirm geblittet. Wie dieser Blit intern funktioniert weiß ich nicht, sehr wahrscheinlich am Ende einer Kette von Qt Objekten, Treibern dann per GPU auf den Bildschirm. Aber ALLE Zeichenoperationen für den Bereich, der am Ende auf den Bildschirm kopiert wird, zeichnet meine CPU in ein char Array. Ich setze jeden Pixel per Hand/CPU, nennt sich Software Rendering. Warum habe ich das gemacht? Nun als erstes hatte ich eh schonmal einen kleinen Software Renderer angefangen und zweites ist diese Methode um einiges schneller gewesen als das was ich über Qt Zeichenbefehler probiert hatte z.B. addLine. Wenn ich dann soweit bin per OpenGL Shader die Sache zu erledigen, dann wird das nochmal einen performanceboost bringen(so hoffe ich zumindest).

Na wenn das hier nicht per CPU ist, dann weiß ich auch nicht^^

void Framebuffer::clear()
{
	memset(adress_, 0, length_);
}

void Framebuffer::fill()
{
	for (int i = 0; i < length_; ) {
		adress_[i++] = color_.b;
		adress_[i++] = color_.g;
		adress_[i++] = color_.r;
		i++;
	}
}

void Framebuffer::fillRandom()
{
	for (int i = 0; i < length_; ++i) {
		adress_[i] = (unsigned char)rand() % 255;
	}
}

void Framebuffer::setPixel(int x, int y)
{
	int offset = (y * yoffset_) + (x << 2);
	adress_[offset++] = color_.b;
	adress_[offset++] = color_.g;
	adress_[offset] = color_.r;
}

[Swordfish]

@chris4cpp sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:

Natürlich zeichnet meine CPU in den Speicher.

Daran ändert aber x-beliebige GUI library nichts. Das tust Du ja bevor das weitergereicht wird.

[Ein ehemaliger Benutzer]

Das bezogt sich auf deine Antwort. Ich habe vorher geschrieben "Aktuell zeichne ich noch mit der CPU" und darauf hin hast du geantwortet: "Deine CPU zeichnet garnichts. Das war mal so..."