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?:
@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.
-
@SeppJ Ähm. Ja. Aber das würde bedeuten daß GUI malen aufwändiger ist als $Arbeit.
-
@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?
-
@SeppJ Naja, wenn GUI malen aufwändiger ist als eigentliche Arbeit dann was falsch.
-
@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.
-
@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.
-
@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.
-
@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.
-
@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:
- GTK+ (oder anderes GUI-Framework)
- Cairo (oder andere 2D-Zeichenbibliothek)
- OpenGL (oder anderes Renderframework)
- X-Server (kann evtl. vom OpenGL-Renderkontext umgangen werden)
- Grafiktreiber im Kernel
- 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.
-
@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.
-
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.
-
@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.
-
@Swordfish sagte in Welches ist die beste GUI-Library + welche Vorgehensweise ist die beste um Grafiken zum Drucken zu erstellen?:
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.
-
@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.
-
@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.
-
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; }
-
@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.
-
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..."
-
@chris4cpp ist ja auch so.
-
Software Rendering heiß mit der CPU zeichnen und am Ende auf den Bildschirm kopieren(entweder per GPU oder sonst wie). Aktuell betreibe ich Software Rendering, würde aber gerne per OpenGL GUI auf Hardware Rendering umschwenken in Zukunft.