Danke für den Hinweis.
Habe den Renderer von Soft auf OpenGL umgestellt, das Problem bleibt.
Ein weiterer Versuch war, mal keinen Text einzugeben und siehe da man kann im Fontauswahlfenster machen was man will DR bleibt auf dem Desktop.
Ein Verdacht den ich habe ist beim auf und abfahren wird in Echtzeit die Schrift des Textes angepasst. Das bedeutet aber auch dass dafür eine gewisse Menge Ramspeicher adressiert werden muss. Wenn nun der Adressvorrat für die nötige Speicherreservierung zu klein ist kommt es zu einer Exception die nicht mehr vom Betriebssystem abgefangen werden kann und Davinci schießt sich ab. Ein weiterer Hinweis ist wenn die Schrift coloriert und extrudiert wird, und man dann die gleichen Spielereien macht, kommt es nicht immer zum Totalabsturz sondern zum Freeze und das ist für den Kernel die Anweisung das Programm auf Halt zu schalten. Es ist dann immer noch im Speicher, weiß aber quasi nicht weiter.
Leider kenne ich die Codierung dieser Subroutine nicht. So bleibt es bei diesen Vermutungen.
Weiterhin ist die Frage warum es nicht bei allen passiert, die Antwort kann in der Nichtidentität der Systeme begründet sein. Denn die Speicheradressierung sollte möglichst reloziebar sein, also verschiebbar im Speicherraum, da hier der Flickerlteppich im Speicher wohl bei jedem anders aussieht verhalten sich die Systeme "naturgemäß" verschieden.
LG Johann
Habe den Renderer von Soft auf OpenGL umgestellt, das Problem bleibt.
Ein weiterer Versuch war, mal keinen Text einzugeben und siehe da man kann im Fontauswahlfenster machen was man will DR bleibt auf dem Desktop.
Ein Verdacht den ich habe ist beim auf und abfahren wird in Echtzeit die Schrift des Textes angepasst. Das bedeutet aber auch dass dafür eine gewisse Menge Ramspeicher adressiert werden muss. Wenn nun der Adressvorrat für die nötige Speicherreservierung zu klein ist kommt es zu einer Exception die nicht mehr vom Betriebssystem abgefangen werden kann und Davinci schießt sich ab. Ein weiterer Hinweis ist wenn die Schrift coloriert und extrudiert wird, und man dann die gleichen Spielereien macht, kommt es nicht immer zum Totalabsturz sondern zum Freeze und das ist für den Kernel die Anweisung das Programm auf Halt zu schalten. Es ist dann immer noch im Speicher, weiß aber quasi nicht weiter.
Leider kenne ich die Codierung dieser Subroutine nicht. So bleibt es bei diesen Vermutungen.
Weiterhin ist die Frage warum es nicht bei allen passiert, die Antwort kann in der Nichtidentität der Systeme begründet sein. Denn die Speicheradressierung sollte möglichst reloziebar sein, also verschiebbar im Speicherraum, da hier der Flickerlteppich im Speicher wohl bei jedem anders aussieht verhalten sich die Systeme "naturgemäß" verschieden.
LG Johann
System:
AMD 3950X, ASUS _Crosshair VIII Hero WiFi, 80 GB Ram, Nvidia 4090 RTX Studio 616.56, chipset AMD X570, chipsetdriver 8.08.12.551, Force MP600 NVMe 2TB, Kingston KC 3000 2TB, Samsung 860 2TB, EIZO Coloredge CG319X, Speededitor, Soundblaster X4, div. HDD, NAS
Soft:
Win 11 Pro 25H2 26200.8973, DR Studio 21.1.0.0014, ACDSee PhotoStudio Ultimate 2026, Affinity Photo 2.6.5, Affinity Designer 2.6.5, Affinity canvas 3.2.2.4646, ShaderMap 4, Vasco da Gama 15 HD Pro, Flowframes 1.39, Helicon Focus Pro 8.3.2, Jwildfire 9.00, Mandelbulb 1.9.9sr39
AMD 3950X, ASUS _Crosshair VIII Hero WiFi, 80 GB Ram, Nvidia 4090 RTX Studio 616.56, chipset AMD X570, chipsetdriver 8.08.12.551, Force MP600 NVMe 2TB, Kingston KC 3000 2TB, Samsung 860 2TB, EIZO Coloredge CG319X, Speededitor, Soundblaster X4, div. HDD, NAS
Soft:
Win 11 Pro 25H2 26200.8973, DR Studio 21.1.0.0014, ACDSee PhotoStudio Ultimate 2026, Affinity Photo 2.6.5, Affinity Designer 2.6.5, Affinity canvas 3.2.2.4646, ShaderMap 4, Vasco da Gama 15 HD Pro, Flowframes 1.39, Helicon Focus Pro 8.3.2, Jwildfire 9.00, Mandelbulb 1.9.9sr39
