@"Chefentwickler"
-
Und kein Look & Feel ist schön.
-
wursel schrieb:
Ja! Gib's ihm!

Und in dem anderen Thread sagst du
wursel schrieb:
Kopf hoch, Gregor! Lass dich von denen nicht entmutigen, ich glaub an dich!

-
Gregor, wie gehts eigentlich deiner (Ex)Freundin?
-
Hey Gregor,
woher bekommst du die sampledaten für solche Spielereien? Ich suche schon lang nach ein paar Samplebildern um ein paar Sachen zu testen, wollte schon fast mal in der Uni fragen (aber die arbeiten meist mit künstlichen Projektionen). Wär nett wenn du mir mal einen Tip geben würdest
-
-
@Korbinian: Eine ganze Menge solche Volumen gibt es da: http://www.volvis.org/
Die liegen da allerdings in einem raw-Format vor. Die Werte der einzelnen Voxel sind also einfach aneinandergereiht in einer Datei abgespeichert. Das reicht natürlich nicht, um so ein Volumen zu laden. Du brauchst noch ein paar mehr Daten wie Höhe, Breite, Tiefe und so weiter. Diese Infos findest du auch auf der Seite. Ich schreibe mir die Dann immer in eine "raw.info"-Datei, die ich zum Laden nutze. Die sieht bei dem Hummer da zum Beispiel so aus:
description = CT scan of a lobster contained in a block of resin. width = 301 height = 324 depth = 56 datatype = UNSIGNED_BYTE x-scale = 1 y-scale = 1 z-scale = 1.4Solche Info-Dateien sind auch mehr oder weniger üblich, aber AFAIK nicht standardisiert. ...zumindest habe ich nie eine formale Beschreibung dieses Formats gefunden. Denk dir also selbst was aus, wenn du da mehr Infos drin brauchst.

-
Chefentwickler schrieb:
Aber eines haben alle Java-GUIs gemein: Sie sind SAU LAHM!!!
azureus ist java und hat ne GTK-Oberfläche, die ist nicht sau-lahm.
-
Aber eines haben alle Java-Swing-GUIs gemein: Sie sind SAU LAHM!!!
-
2 schrieb:
Aber eines haben alle Java-Swing-GUIs gemein: Sie sind SAU LAHM!!!
Ja? Weiß nicht. Kannst du da mal quantitative Angaben machen? Zum Beispiel durch nen Benchmark, in dem Swing mit anderen GUI-Toolkits verglichen wird?
Zumindest bei meinem Programm kann ich eindeutig sagen, dass das Problem nicht die Geschwindigkeit des GUI-Toolkits ist. Wenn man Datensätze darstellen will, die teilweise bis zu 170MB groß sind, dann kommen Performanceprobleme sicherlich nicht dadurch, dass irgendein Label doppelt so lange zum Zeichnen braucht als bei nem anderen Toolkit.
-
QT ist außerdem auch saulahm...
Wenn wir schon beim bashen sind

-
Ringding schrieb:
QT ist außerdem auch saulahm...
Wenn wir schon beim bashen sind

QT ist aber cool

-
GUI-Systeme sind fast nie so lahm, dass ein kümmerlicher Mensch das sehen würde. Der Hauptpunkt ist hier immer die gefühlte Performance: Man drückt nen Knopf und es dauert ne Sekunde, bis das Ergebnis da ist. Das kann man durch rumblinkendes Klickibunti ganz erheblich verhindern.
Wenn ich in der Windows-Systemsteuerung bei den Darstellungsoptionen was verändere und auf OK drücke, bleibt der Button auch für eine Sekunde lang eingedrückt. Ich würde allerdings nicht vermuten, dass es so lange dauert, den Button wieder grafisch hochschnellen zu lassen.
In Eclipse wenn ich zum ersten mal nen Rechtsklick im Code-Editor mache, dauert es ne Sekunde bis das Menü da ist. Das liegt auch nicht am lahmen GUI, sondern daran, dass die entsprechenden Plugins zum ersten mal geladen werden (von der Platte!).
-
Fast alle Java-GUI-Programmierer sind schlecht.
-
Optimizer schrieb:
GUI-Systeme sind fast nie so lahm, dass ein kümmerlicher Mensch das sehen würde.
In den meisten Fällen stimmt das. Aber beim Scrollen in Listen/Trees o.ä. ganz und gar nicht. Da macht es einen großen Unterschied, ob das Ding mit der Samplerate der Maus mitkommt oder ob nur 10-20 fps gezeichnet werden, wie es bei QT üblicherweise der Fall ist.
-
Ringding schrieb:
QT ist außerdem auch saulahm...
unter windows?
-
DrGreenthumb schrieb:
unter windows?
Ja.
Unter Linux ist alles saulahm (was mit GUIs zu tun hat, meine ich...).
-
Ringding schrieb:
DrGreenthumb schrieb:
unter windows?
Ja.
Unter Linux ist alles saulahm (was mit GUIs zu tun hat, meine ich...).
Troll oder ernst?
-
sicher? schrieb:
Troll oder ernst?
Troll.
-
Ernst.
Zeig mir mal irgendwas grafisches, das unter Linux wirklich zügig auf einer 300MHz-CPU läuft. Unter Windows absolut kein Problem.
-
Das stimmt nur teilweise fazit.
Schau dir mal beliebige Programme an: wenn du auf irgendetwas klickst, gibts erstmal ein graphischer Gimmik, dann darf man ein paar (Milli)-Sekunden warten, dann erst kommt das Resultat.
"Warten" ist also ganz natürlich (und man ist sich auch daran gewöhnt).
Die Frage ist nur "wann" darf man den Benutzer warten lassen? Sicherlich nicht dann, wenn er gerade in Höchstform ist, und auf einen Knopf gedrückt hat. Dann muss *irgendwas* passieren. Was, ist hingegen total egal.Ich sitze gerade an einem Programm das Interviews auswerten soll. Jede Auswertung (=alles mit allem nach gewissen Kriterien vergleichen) benötigt rund 2-4 Sekunden. Da ich einen eigenen Thread für diese Berechnungen benutze, können Buttons und Menüs gleich nach einem Klick zurück in die Ursprungsgestalt springen (=es passiert was). Der Effekt: das Programm wirkt extrem schnell obwohl der Benutzer sekundenlang warten muss.
Besonders Anfänger, auch auch manch "Fortegschrittener", kennen diese (psychologischen und programmtechnischen) Tricks nicht. Von diesen Leuten kommen dann die Programme mit den trägen Oberflächen. Insofern sind sie nicht "schlecht", sondern schlicht und einfach "unerfahren".