Hallo Besucher, der Thread wurde 18k mal aufgerufen und enthält 130 Antworten

letzter Beitrag von angryking am

VICE 3.x experimental Gtk3 threaded-UI build

    So wie ich die Texte (auch als Nicht-Programmierer) verstanden habe, ist der eigentliche Code von GTK nicht Schuld am Problem, sondern eher das generelle "Programm-Design-Verhalten". Und mit der Auslagerung des eigentlichen Emulator-Threads ist das Problem wohl umgangen. Somit ist GTK ja schon irgendwie "Schuld" - auch wenn das als unerwünschter Nebeneffekt entstanden ist.


    Aber wirklich klasse, dass auch angestossen durch "Denise" hier ein großes Problem beseitigt wurde.


    Nur: Wieviele andere wichtige Dinge müssen denn vorher noch umgesetzt werden? Bzw. übernommen werden?

    Keine Polemik, allein die Frage, was in dieser WinVice noch als Feature fehlt (oder Bugfixes?).


    Wahnsinn, dass man nach so langer Zeit immernoch Dinge in findet, die man implementieren oder fixen kann.

    Zitat von AW182
    (4) i configured my "autostart" settings here in this version, like i always did in all older VICE versions, but in V3.4 it works for me though, that onefilers inside a d64 start by their own, without that i need to type in the word "run" and press Return, but it don't work for prg-files which are directly on my PC harddrive. These files were loaded, but then not started automatically anymore. Is that supposed to be that way now in newer versions, or not? I ask, because i also saw, that the word "autostart" is gone now in the name of this function and that it now is called "smart attach" in the newer versions, so maybe it was planned to change this starting-behaviour? But i liked it, that also prg-files started by themselves in older versions, has it a certain reason why this was changed?


    The autostart-on-double-click is a bit of a contentious thing. Some people like to autostart anything when double-clicking, some don't. The main issue is that there aren't a lot of examples of how to handle this (ignoring emus). Personally I think double-clicking on a file should open (attach) that file, a bit like opening a .bat of .sh file from an editor, you can be pretty sure the intention is to open the file for editing, not running it.


    Then there's the multi-disk demos or games: where double-clicking the next image would autostart the image and the demo or game would fuck up. So I prefer a separate 'Autostart' button.

    To be fair to GTK - we were not using it in the way that it is meant to be used. As the GTK developers themselves reminded us, it's a UI toolkit not an emulator / game toolkit. They accepted one patch that improved GtkGLArea OpenGL performance on macOS, and have not accepted another general performance improvement patch.


    But to be clear - the new threaded native window rendering code would return the exact same performance that we see today had they not accepted any patch from me. We needed to change how we were using GTK, and we have.

    Overall a really welcome change, thanks for doing the hard work. You could've let it as is.

    Plus the new binary remote monitor interface rocks, debugging speed with C64Studio is now almost instant, where before it could take up to a few seconds; depending on how many memory fetches were required.


    Good stuff!

    Zitat von AW182

    Jetzt lag's also auf einmal an meinem Englisch *lol*.

    Was ich geschrieben habe kann ja jeder hier nachlesen, ebenso wie dein komplett falsches Verständnis davon. Sprachschwierigkeiten wären eine naheliegende Erklärung, weitere Spekulationen spare ich mir, da es letztlich keine Rolle spielt.

    Zitat von AW182

    Dass diese Ruckelproblematik nichts mit GTK zu tun hatte, war nunmal nichts anderes als eine Fehleinschätzung.

    Ich wundere mich ernsthaft, dass dir das nicht langsam doch mal peinlich wird…

    Zitat

    But to be clear - the new threaded native window rendering code would return the exact same performance that we see today had they not accepted any patch from me. We needed to change how we were using GTK, and we have.

    Zitat von dqh_

    To be fair to GTK - we were not using it in the way that it is meant to be used. As the GTK developers themselves reminded us, it's a UI toolkit not an emulator / game toolkit. They accepted one patch that improved GtkGLArea OpenGL performance on macOS, and have not accepted another general performance improvement patch.


    But to be clear - the new threaded native window rendering code would return the exact same performance that we see today had they not accepted any patch from me. We needed to change how we were using GTK, and we have.


    Okay, but this statement now contradicts previous given statements like


    Compyx wrote:

    DQH put a lot of effort into this, even submitting patches for Gtk/GDK and going out of his MacOS comfort zone and work on Windows and Linux as well.


    Sounds for me, that patches for GTK would have been necessary, to solve the problem and not, that the GTK team don't accepted all these patches.


    Unseen wrote:

    Yes, it would be nice if the GTK team would actually accept all of our patches... As far as I know the Mac version still has a rather high CPU usage because GTK does some things every single frame that should only be needed once per window resize.


    And this sounds like, that they not accepted only the patches for MAC, but the ones for Windows they did accept. In Windows it works now like it should, in MAC it has a high CPU usage, cause they have not accepted the patches for it - this is the statement i read out of these sentence.



    Then this is wrong and the problem the whole time was, how GTK was used and this now could be solved by tips, given by the GTK team, or what is the truth now?



    Zitat von compyx

    Vielleicht muechten Sie Beide einen Zimmer suchen? =)

    But only with separate beds. :)

    Zitat von Hagtrix

    So wie ich die Texte (auch als Nicht-Programmierer) verstanden habe, ist der eigentliche Code von GTK nicht Schuld am Problem, sondern eher das generelle "Programm-Design-Verhalten". Und mit der Auslagerung des eigentlichen Emulator-Threads ist das Problem wohl umgangen. Somit ist GTK ja schon irgendwie "Schuld" - auch wenn das als unerwünschter Nebeneffekt entstanden ist.

    So verstehe ich das ebenfalls, wenn ich die Texte lese.


    Zitat von compyx

    The autostart-on-double-click is a bit of a contentious thing. Some people like to autostart anything when double-clicking, some don't. The main issue is that there aren't a lot of examples of how to handle this (ignoring emus). Personally I think double-clicking on a file should open (attach) that file, a bit like opening a .bat of .sh file from an editor, you can be pretty sure the intention is to open the file for editing, not running it.


    Then there's the multi-disk demos or games: where double-clicking the next image would autostart the image and the demo or game would fuck up. So I prefer a separate 'Autostart' button.


    Yes, it's a contentious thing, i guess. I thought it could make sense for prg's, crt's, t64's and p00's. For d64-Files, that's true, the sense is doubtful, for them it makes not that much sense, to autostart by doubleclick. For these other mentioned filetypes, it could be thought about.

    One patch was accepted, the rest not: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1441

    Nothing to do with Windows, MacOS or Linux. All of these would have benefited from these patches.


    The Gtk/Gnome team weren't exactly helpful, as you can read above. Seems we tend to do what the Gnome devs say not to do, or at least don't want to think about.

    AW182 und Zirias/Excess Jetzt ist auch mal genug. Euer ständiges "Du hast gesagt und Du hast behauptet" hin und her NERVT nur noch seit Ihr damit angefangen habt.

    Schaltet BEIDE mal Euer Egos einen Gang runter! Man kann auch mal die Meinung eines Anderen einfach mal stehen lassen und das Leben geht weiter.

    Zitat von compyx

    One patch was accepted, the rest not: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1441

    Nothing to do with Windows, MacOS or Linux. All of these would have benefited from these patches.

    So, apart these one patch, only the way was changed, how GTK was used? Strange. But okay, it shall be true.


    Zitat von compyx

    The Gtk/Gnome team weren't exactly helpful, as you can read above. Seems we tend to do what the Gnome devs say not to do, or at least don't want to think about.

    At least they reminded, that it's a UI toolkit not an emulator / game toolkit. *lol* I just wonder, how it could work normally on some Windows-machines even before that update here, cause some people always said, that they had no stutter-problem. They had newer and stronger PC hardware then and don't ran into that problem, or how could that be?


    Zitat von syshack

    Man kann auch mal die Meinung eines Anderen einfach mal stehen lassen und das Leben geht weiter.

    Lebbe gehd weida, willst du damit sagen? Möglich möglich... :)

    I put a lot of effort into trying to make the existing single threaded codebase work well before I decided that we'd never get the right outcome without putting VICE on its own thread. I spent a lot of time trying to get THAT working well everywhere (with decent results) before deciding to ditch GTK's built in support for OpenGL and implement a native window overlay with full control of DirectX, which is the build you see shared here. It's been a long journey and different efforts applied to different phases focused on different problems for different reasons. But here we are - VICE GTK Windows is now finally in a good place and macOS & Linux are soon to follow.


    Hopefully sharing some of the details here will give some ideas to anyone who is facing similar problems with their project. Any single threaded emulator is going to have problems if UI toolkit code can block the CPU for more than 10ms or so. GTK is much slower than native UI toolkits which is why some of these problems got worse - but any single threaded code base is going to have these sorts of problems at some level. The architecture was to blame, not GTK, which isn't to say that GTK didn't or doesn't have inherent problems as well.

    syshack Der Grundsatz "jeder hat ein Recht auf seine Meinung" ist gut und richtig, bezieht sich aber auf Themen, bei denen es keine objektive Wahrheit gibt, wie die Klassiker Politik und Religion, oder auch Geschmacksfragen und Vorlieben. Ihn darüberhinaus ausdehnen zu wollen ist völlig absurd und führt nur zu Verwirrung, Verbreitung falscher Informationen, und wie bei diesem Thema zu sehen war sogar zu üblen Beschimpfungen. Es ist zwar völlig ok, auch Vermutungen zu äußern – wenn einem dann aber jemand, der sich mit dem Thema etwas besser auskennt, sagt, dass die Vermutung falsch ist, wäre es an der Zeit, es "gut sein" zu lassen. Desweiteren wäre es höchste Zeit, dass diese öffentlichen Zurechtweisungen aufhören, und ich verbitte mir das ausdrücklich. Wer auf der Metaebene etwas zu meckern hat kann jemanden direkt ansprechen, das sollte eigentlich erst recht mit einem Mod-Status gelten. Sollte das hier so weitergehen werde ich für mich persönlich die Konsequenz ziehen müssen.

    Zitat von dqh_

    to ditch GTK's built in support for OpenGL and implement a native window overlay with full control of DirectX

    I wasn't aware GTK itself supports OpenGL rendering as this isn't exactly the domain of a UI toolkit, but always assumed that on the Windows platform, DirectX would be the better choice anyways. Now, not using GTK for actual rendering sounds like the sane choice :) Just maybe an idea to avoid having too much platform-specific code again: Wouldn't it be possible to use SDL for the rendering window? AFAIK, SDL already uses the "best" backend for good rendering on all supported platforms, so this might reduce platform-specific code to just a bit of "glue". Of course I might be all wrong here, it's just a suggestion :)

    Zitat von AW182

    how it could work normally on some Windows-machines even before that update here, cause some people always said, that they had no stutter-problem. They had newer and stronger PC hardware then and don't ran into that problem, or how could that be?

    As for me, I only tried on a (rather modern and powerful) Surface book, so this assumption is probably correct. From what was written here, VICE has always been single-threaded, and GTK hogs the CPU for rendering the GUI more on Windows than it does e.g. on Linux, so it just comes down to how fast a single Core on your machine is. If it's fast enough that the "stalls" introduced by GUI code via GTK are short enough not to affect the emulation, it will work fine. When you have a timing-critical job (like emulating a machine) to do, it's always the wrong design to do it in the same thread as something interactive like a GUI, but multi-threading is much more complex and hard to get correct (especially in C), so, a lot of complex work was done here :thumbup:. The fact that GTK rendering is faster on Linux (or, probably, on systems with X11 backend, which includes e.g. BSDs) lead to the fact that on the same hardware, VICE seemed to work fine on Linux, but maybe not on Windows.

    Zitat von Zirias/Excess
    Zitat von dqh_

    to ditch GTK's built in support for OpenGL and implement a native window overlay with full control of DirectX

    I wasn't aware GTK itself supports OpenGL rendering as this isn't exactly the domain of a UI toolkit, but always assumed that on the Windows platform, DirectX would be the better choice anyways. Now, not using GTK for actual rendering sounds like the sane choice :) Just maybe an idea to avoid having too much platform-specific code again: Wouldn't it be possible to use SDL for the rendering window? AFAIK, SDL already uses the "best" backend for good rendering on all supported platforms, so this might reduce platform-specific code to just a bit of "glue". Of course I might be all wrong here, it's just a suggestion :)

    You are quite right to point out that we should look at using SDL - now that I've proven the concept with DirectX, i've been asking myself why I wouldn't just do that rather than battle with Apple's deprecation of OpenGL etc. Perhaps I will.

    Zitat von Zirias/Excess

    Desweiteren wäre es höchste Zeit, dass diese öffentlichen Zurechtweisungen aufhören, und ich verbitte mir das ausdrücklich.

    Wenn Diskussionen aus dem Ruder laufen, weisen die Mods darauf hin.

    Das wird hier im Forum so gehandhabt und ganz sicher werden wir das nicht ändern. Damit solltest Du schon Erfahrung haben - genug eigentlich.

    Oftmals ist es so, dass man sich in etwas hineinsteigert und das selbst gar nicht merkt, bis man dann darauf aufmerksam gemacht wird.

    Unterm Strich also eine Win-Win-Situation - wenn man denn bereit ist, das auch mal für sich zu akzeptieren.


    Euer permanentes Hin und Her (und JA, damit seid Ihr BEIDE gemeint) ist wirklich nicht mehr christlich. Du kannst Leute nicht reformieren, wenn sie es nicht wollen. Entweder sie akzeptieren Deine Meinung nach Überlegen und ändern ihre eigene - oder eben nicht. Tust Du ja hier auch nicht - und womit? Mit Recht - wie Du es ja siehst.

    Andere Leute, andere Meinungen - und wenn man merkt, dass man die anderen nicht überzeugen kann, und seien die Argumente NOCH so stichhaltig - dann lässt man es eben. Es führt ja zu nichts - wie man hier sieht.


    Das sollte muss als letzter Hinweis genügen.

    Zitat von controlport2

    Wenn Diskussionen aus dem Ruder laufen, weisen die Mods darauf hin.

    Wenn man den Bedarf hat, das zu tun, gibt es immer die Möglichkeit, jemanden direkt anzuschreiben. Öffentliche Maßregelungen sind absolut daneben und werde ich auch niemals akzeptieren. Das ist auch mein gutes Recht, denn ich fordere nur eigentlich selbstverständliches ein: Mit mündigen erwachsenen Menschen geht man nicht um als wären es Untergebene oder vielleicht die eigenen Kinder. Natürlich kann ich niemandem vorschreiben, wie er "sein" Forum zu "führen" hat. Ich muss daran aber nicht teilnehmen, wenn ein derart inakzeptabler Stil vorherrscht.

    Zitat von controlport2

    Entweder sie akzeptieren Deine Meinung

    Es gibt einen sehr relevanten Unterschied zwischen Meinungen und Tatsachen bzw objektiv falschen Behauptungen, wie oben bereits ausgeführt.

    Zitat von controlport2

    Um zumindest DIESE Diskussion hier zu beenden hat Zirias jetzt zwei Wochen Zeit zum Nachdenken.

    Dass Du Zirias sperrst, um eine "Diskussion zu beenden", ist leider genau das Verhalten, das Zirias oben - zu Recht - bemängelt.


    Ich gehe davon aus, dass gleich das Argument kommt: "In den NUBs steht aber, dass den Anweisungen der Mods Folge zu leisten ist" - hier wurden aber keine Anweisungen gegeben, denen nicht Folge geleistet wurde.


    Würden Mods bei Kritik - sowohl an sich selbst als auch an anderen Moderatoren - nicht immer gleich den unerträglichen Korpsgeist auspacken, würden solche Konflikte deutlich weniger ausarten.