Hallo zusammen,
ich wollte mal nachfragen, welche der vielen Grafikbibliotheken ihr für am schnellsten haltet. Auch wenn man das vielleicht so nicht beantworten kann gibts da sicher eine Reihenfolge.
Ich meine vor allem 2d-Grafik.
ich vermute, dass pygame da nicht so verkehrt ist, immerhin ist es zur spieleentwicklung gedacht.
Was meint Ihr?
Gruß
Nko
Echtzeitgrafik - welche Bibliothek?
pygame basiert auf SDL und das unter Linux wiederum auf Framebuffer und Xlib. Hardware-Beschleunigung gibt es da, soweit ich mir das gerade anlesen konnte, nicht. Es besteht aber die Möglichkeit, SDL gemeinsam mit OpenGL zu verwenden (also wohl direkt OpenGL-Calls zu machen), um in den Genuss von Hardware-Beschleunigung zu kommen.
Dann ist da natürlich noch Pyglet, das im Gegensatz zu Pygame den Vorteil hat, dass es halbwegs lebt, sprich weiterentwickelt wird. Das verwendet ctypes, keine Ahnung, obs dadurch langsamer wird. Auf jeden Fall benutzt das auch OpenGL für 2D.
@fk: Von Pygame gab's im Juli ein Release. Würde ich also nicht als Tot bezeichnen.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Also vor dem 1.8 Release sah gab es schon einige Zeit ziemlichen Stillstand.BlackJack hat geschrieben:@fk: Von Pygame gab's im Juli ein Release. Würde ich also nicht als Tot bezeichnen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
hmm,... gut
pygame hatte ich schonmal angetestet. Bin aber nicht weit gegangen. Hab grad wo gelesen, daß pygame für os-icks nicht so einfach geht. ( mir persönlich erstmal egal , aber gut)
Pyglet hab ich mir heute ein bisschen angeschaut und scheint auch was vernünftiges zu sein. Hat mir aber scheinbar gerade mal meinen Computer eingefroren. Mal sehen. Also pygame oder pglet scheint die Wahl zu sein.
pglet ist wohl rudimentärer, ist aber wahrscheinlich eher das, was ich suche. Die "Physik" selber programmieren. Also Formen und Farben in Echtzeit generieren und ändern. Echtzeit sollen Datenströme sein, also z.B. n Mikro.
Ich werd da mal ein bisschen weiter suchen und dann wohl wieder in [Sonstige (PyQt, Pygame, PyOpenGL, ...)] posten.
Dann Dank erstmal.
pygame hatte ich schonmal angetestet. Bin aber nicht weit gegangen. Hab grad wo gelesen, daß pygame für os-icks nicht so einfach geht. ( mir persönlich erstmal egal , aber gut)
Pyglet hab ich mir heute ein bisschen angeschaut und scheint auch was vernünftiges zu sein. Hat mir aber scheinbar gerade mal meinen Computer eingefroren. Mal sehen. Also pygame oder pglet scheint die Wahl zu sein.
pglet ist wohl rudimentärer, ist aber wahrscheinlich eher das, was ich suche. Die "Physik" selber programmieren. Also Formen und Farben in Echtzeit generieren und ändern. Echtzeit sollen Datenströme sein, also z.B. n Mikro.
Ich werd da mal ein bisschen weiter suchen und dann wohl wieder in [Sonstige (PyQt, Pygame, PyOpenGL, ...)] posten.
Dann Dank erstmal.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo!
Nur der Vollständigkeit halber:
wxPython hat mit dem wx.GraphicsContext die Möglichkeit, unter Windows direkt mit der GDI-Library zu zeichnen. Und unter Linux wird automatisch Cairo zum Zeichnen verwendet. Schau' dir einfach mal die wxPython-Demo an.
Wem das zu langsam ist -- und falls es wirklich etwas bringt, das weiß ich nicht -- der kann noch mit dem wx.GlCanvas direkt mit OpenGL arbeiten.
So viel ich weiß, haben pyGTK (das war eh klar) und pyQt auch die Möglichkeiten, direkt mit Cairo zu zeichnen. Ich denke, dass beide GUI-Toolkits auch mit OpenGL klar kommen.
mfg
Gerold
Nur der Vollständigkeit halber:
wxPython hat mit dem wx.GraphicsContext die Möglichkeit, unter Windows direkt mit der GDI-Library zu zeichnen. Und unter Linux wird automatisch Cairo zum Zeichnen verwendet. Schau' dir einfach mal die wxPython-Demo an.
Wem das zu langsam ist -- und falls es wirklich etwas bringt, das weiß ich nicht -- der kann noch mit dem wx.GlCanvas direkt mit OpenGL arbeiten.
So viel ich weiß, haben pyGTK (das war eh klar) und pyQt auch die Möglichkeiten, direkt mit Cairo zu zeichnen. Ich denke, dass beide GUI-Toolkits auch mit OpenGL klar kommen.
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Scheint mir, du willst sowas wie Processing haben/bauen. Darum gibt's auch irgendwo einen Python-Wrapper.
An gerold anknüpfend: Für wxPython gibt's einen OpenGL-Frame, den hab ich vor längerer Zeit mal benutzt.
An gerold anknüpfend: Für wxPython gibt's einen OpenGL-Frame, den hab ich vor längerer Zeit mal benutzt.
Bei 2D-Zeichenoperationen profitiert SDL immer auch von der Hardwarebeschleunigung des Treibers (so er diese bietet). Außerdem unterstützt SDL den Gentoo-Useflags nach zu urteilen mehrere Video-Backends. Für beschleunigte 3D Zeichenoperationen muss man aber direkt auf OpenGL zugreifen, dass stimmt schon.Y0Gi hat geschrieben:pygame basiert auf SDL und das unter Linux wiederum auf Framebuffer und Xlib. Hardware-Beschleunigung gibt es da, soweit ich mir das gerade anlesen konnte, nicht.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
PyQt bietet GraphicsView, womit man Canvas-like zeichnen könnte, bei PyGTK nimmt man da gnome-canvas oder goo-canvas oder soetwas. Ob die für schnelle Grafiken brauchbar sind: keine Ahnung.gerold hat geschrieben:So viel ich weiß, haben pyGTK (das war eh klar) und pyQt auch die Möglichkeiten, direkt mit Cairo zu zeichnen. Ich denke, dass beide GUI-Toolkits auch mit OpenGL klar kommen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
QGraphicsView ist darauf ausgelegt, eine große Anzahl von 2D-Grafiken schnell darzustellen. Für 3D Grafiken gibt es QtOpenGL. QtOpenGL.QGLWidget kann man auch nutzen, um primitive 2D-Zeichenoperationen mittels OpenGL zu beschleunigen.
...SDL, Cairo, OpenGL...
sind also die zugrunde liegenden Bibliotheken. Schnelligkeit scheint noch nicht so genau untersucht zu sein.
Dann werd ich das Thema jetzt nochmal anders anpacken: Welche der Pythonbindings ist denn am "einfachsten" zu bedienen? Ja, eine subjektive Frage, aber dennoch. Mit möglichst wenig drumherum.
Danke, bis dann.
sind also die zugrunde liegenden Bibliotheken. Schnelligkeit scheint noch nicht so genau untersucht zu sein.
Dann werd ich das Thema jetzt nochmal anders anpacken: Welche der Pythonbindings ist denn am "einfachsten" zu bedienen? Ja, eine subjektive Frage, aber dennoch. Mit möglichst wenig drumherum.
Danke, bis dann.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Nko!Nko hat geschrieben:Welche der Pythonbindings ist denn am "einfachsten" zu bedienen?
So wie es im Moment für mich aussieht, ist Cairo sehr, sehr einfach zu bedienen. Siehe: http://www.python-forum.de/post-115996.html#115996
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.