Hello, Guest the thread was called3.6k times and contains 118 replays

last post from DivZero at the

VICE 3.x experimental Gtk3 threaded-UI build

  • What we'd like to know is if it works better than current trunk/nightlies and if there are issues, or stuff that does work, please report them here. We're also interested in reports of people who have monitors that aren't fixed to 50 or 60 Hz, but can set to the proper frequencies, or monitors that can adjust to them, ie the g-sync/freesync stuff.


    I have seen this only five minutes ago and made a fast testing on my hardware.


    Scrolling is much much better now in this version, compared to older GTK3-VICE's, on my BenQ BL912 monitor, when i let the emu run in 50Hz fullscreenmode. Big improvement, the big stuttering is completely gone. Great! From time to time (about every 30 to 40 seconds) i have one little stutter, but which is manageable. Maybe this one stutter is because of 50,125Hz speed to 50,000Hz fullscreen-Hz? Or will this version sync to the monitor-Hz in fullscreen, i have not read the whole thread now, because i wanted to make a fast test and then i must go anyway in 10 minutes.


    But good work, now this version is finally usable on my PC, which is cool. Today in the evening i am back, then i test around with some demos and games in this new version and when i find a bug, i report it.


    Just one last thing - users which don't have a freesync monitor, must set their Windows in 50Hz mode every time, before running GTK3-VICE, to have a 50Hz fullscreen-mode then in the emulator-fullscreen. Even when i can do this very fast now in the meantime, cause i made me two icons on the Windows-taskbar with NirCMD commandline-commands for switching the Hz with only one mouse-click, it would not be bad, when the emulator could to this by it's own, like it was in former times. The possibility, to set a fixed fullscreen-resolution together with a Hz-value in the video-settings of WinVICE, was a nice thing. Maybe something like this should be brought back, cause not all users have freesync-monitors, or at least, it should be thought about if it not makes sense, bringing back something like this. For example, in HOXS this found it's way in the emulator only with version 1.0.23.0 on 25. Sept 2019 and now it's there (cause it makes sense) and in DENISE this is planned to come soon. The older VICE versions had it for alot of years and then it was removed sadly, never really understood why. Maybe there is a chance to bring back something like this, it saves the users with non-freesync-monitors, from having to change the Hz every time in Windows to 50Hz, before starting VICE.

  • I have tested the new version a little bit on my PC with different software and some things i found out:


    (1) scrolling is pretty good now, as i mentioned before. it is not 100% smooth on my PC here, from time to time it stutters one or two times, but overall it is close to the scrolling of the native WinVICE version now and also i have not that soundbuffer-bug when running a 50Hz fullscreen-mode in this version here, which is good.


    (2) but some strange behaviours i also have. when i exit the new version, it goes on running as a task on my Win7, 32bit system. i found this out, because one time i had an ongoing sound-effect after the emulator was closed. then i looked into the task-manager and saw, that there were five vice emulators (x64sc.exe) still running at the same time. before i had opened and closed the new version different times and all these versions still were running as tasks in the background, so i have to close them all manually in the task-manager. i always must do this now, otherwise this new version is not completely closed when i click "exit emulator". there seems to be a problem with finishing the emulator on my Win7, 32 bit system.


    (3) then i recognized a problem with the controllers in the "input devices" menue. on my PC here, i have eight different controllers connected all the time. some of them directly, some with different adapters. in the "Joystick-list" of the new GTK3 version, i can see all these controllers normally, but it is only possible for me, to use the first five of them in this list with this version here. The controllers number six, seven and eight, i can choose, but when i leave the "input devices" menue one time and then return to it, they are not chosen anymore. then i tried to change the numbers of the used controller directly in the vice.ini file, but it also don't work. Every number higher then 5, the emulator dont use and change back by itself when one time startet. this is especially annoying, because just my Retrodonald 9Pin-to-USB adapter is controller number six and seven on my PC and these i can not use at the moment in this version here. Strange, i tested around in SDL2 VICE V3.3 and WinVICE V3.2 and there i can use all my controllers, also such above the fifth in the joystick-list. There must be a little problem with the joysticks, here in GTK3 V3.4 i guess. Also it seems that the overall joystick-settings was simplified, compared to the WinVICE joystick-settings, in which the user had things like autofire and could set, which buttons to use for fire. I guess, this will also come here, but sometime later?


    (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?


    (5) sometimes on my PC, the sound-emulation cames out of step, i also recognized. tested around with different demos and sometimes in the beginning when i start a certain software, the SID emulation sounds strange (sometimes i had a hall-effect), then after some seconds, it was okay again. never had these phenomenon in the native WinVICE versions so far. could it have something to do, with how much Hz the screenmode is running maybe?


    (6) a last question about the audio. in the SID settings i saw, that the "8580 filter bias" now by default is set to -3000 instead of +500. is this correct and the user should let this unchanged or is recommended to set it again to +500 which was the standard-setting in the WinVICE versions? or has this bias-change something to do with the new filter, that was discussed in another thread days ago?


    (7) all things concerning the speed-settings of the emulator seemed to be taken out of the user-menue, right? it is not possible now, to let this version run in a certain custom-speed, or have i overlooked this option when i searched for it? Great would be, when the user could decide by himself if he wants to let the emulated C64 run in 50,125 FPS or in 50,000 FPS, when this maybe brings him the advantage of smoother scrolling on his monitor. This would mean, giving the user the possibility to choose between 100% speed and 99,75% custom-speed. I know that not all VICE members like, when the speed is not 100% correct, but giving the user the possibility to choose between both, 50,125 and 50,000 would be a good compromise for all. then every user could decide by himself, in the same way, that the users could decide in the older WinVICE versions to let the emu run in 101% or 99% custom speed when they want to. Nothing would be lost by giving the possibility to switch between 100% and 99,75% speed but it could be beneficial for the scrolling on certain graphic-cards and monitors. I guess with this



    Overall this new GTK3 version now is much more usable on my PC than the older GTK3 versions was, even when it still had some smaller problems. But, the big stuttering-problem has improved alot. Good work.

  • First of all, thanks for testing and the rather verbose reply :)


    Good to know this build runs a lot better, that was the goal. 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.


    I'll only comment on the non-rendering/sync stuff, dqh is in much better position to answer that, he wrote all the new code.


    So:

    • I cannot reproduce the x64sc.exe hanging around after closing, I've used a Win7 64-bit VM and ran both 32-bit and 64-bit builds. But this might be something we have to test on actual win32.
    • The joystick settings were indeed simplified since only WinVICE had a semblance of support for auto-fire and other buttons, although the code was broken and the UI incomplete. I'm working on code to allow for more devices (though I do not have 8 devices, so someone will need to test it for me) and also mapping buttons to the keyboard, meaning you can use extra buttons to, for example, use special weapons in Turrican, or switch weapons in Hawkeye, with the controller. Auto-fire is also on my TODO list. Merging this branch with trunk takes precedence, so it'll probably not turn up soon.
    • Autostarting .prg's from the host should work, the dialog should have an 'Autostart' button.
    • You can access the old 'speed' menu by left-clicking on the cpu/fps widget in the statusbar, there you can set a custom speed, although only with integer precision. dqh is in a better position than me to explain why we don't use floats.


    Hopefully this makes at least some things a little more clear.

  • 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.

    And that definately paid off, big improvement. Not only on my PC, some hours ago i tried it on the PC of my cousin and also there the big stuttering problem is gone now. On his PC (Win7, 64bit system) VICE correctly closes after exiting emulator. Strange that my PC has a problem with that, i will try around later today, to find out what could go wrong here or if i could solve this somehow in the commandline of the GTK3VICE desktop-shortcut.


    • You can access the old 'speed' menu by left-clicking on the cpu/fps widget in the statusbar, there you can set a custom speed, although only with integer precision. dqh is in a better position than me to explain why we don't use floats.

    Aaah i see, there are the speed-settings, not so easy to find. :) Sadly, like you mentioned, it's like in native WinVICE in this point and also here only integer-values work, which then don't correspond to integer Hz-values then. But it must work somehow to get 50,000Hz, cause "Lipti's" WinVICE Testbuild does it and runs in that speed (which is 99,75%) and there the scrolling on my hardware is perfect. Sadly "Lipti" has still not published this version and i am still the only person which have a testbuild of this which i should not give out. Not ideal situation, i hope a version will be published by "Lipti" in nearer future. When non-integer speed-values makes problems, it would completely be enough, to let integer-values in the custom-speed field, but instead including a new click-option which is called something like "use 50.000Hz Mode"



    and when this is clicked the emulated C64 should run in exactly that speed. When not clicked, then in the original 50.125Hz.


    • Autostarting .prg's from the host should work, the dialog should have an 'Autostart' button.

    Indeed, found this button now in the "smart attach file dialog" and with this, it works to let also prg files autostart. It could maybe not be a bad idea, to let the most filetypes (including prg's) also autostart, when they are doubleclicked with the Mouse. I guess, the most people will start files by doubleclicking them and also the most people want, that these files then start automatically without that the user must type "run". There is also a "open" button in smart attach dialog, which don't autostart files, if a user needs that, therefore one could think about changing the doubleclick-behaviour and let all files autostart when doubleclicked. Just a suggestion, think it could make sense for faster handling.

  • I always said it's a good idea to move to a single UI for all target systems, as the time spent maintaining many of them is better spent on other issues, and if there are issues on some Windows systems, give the guys some time to figure it out :D Well, yes, that's the (obligatory) rarely-appreciated "I told you" post, just couldn't resist :P


    As for the actual news, congrats to the team, seems you (mostly) satisfied anyone wanting to use VICE for games/demos on Windows, so great work! :thumbsup:


    (Reminds me to pick up my testing on FreeBSD again, as I still have VICE 3.3 there for my daily needs, because 3.4 somehow dies for memory exhaustion. The current trunk seems to work better, but there are other issues -- will continue to investigate soon compyx ;) )

  • Quote

    I cannot reproduce the x64sc.exe hanging around after closing, I've used a Win7 64-bit VM and ran both 32-bit and 64-bit builds. But this might be something we have to test on actual win32.

    I can confirm that the x64sc.exe and x64.exe doesn't really close after you've quit the emulator (still running in the Task Manager). Happens with the 32bit and 64bit builds from yesterday. Windows 10 v1909 64bit here on my side. And if you ran something with music before you close the emulator it really hangs with an annoying sound.

  • I always said it's a good idea to move to a single UI for all target systems, as the time spent maintaining many of them is better spent on other issues, and if there are issues on some Windows systems, give the guys some time to figure it out :D Well, yes, that's the (obligatory) rarely-appreciated "I told you" post, just couldn't resist :P


    Seeing it from the user-side, i don't care much about, if one single UI is used for alle target systems or if native UI's are used for that, the most important point for users always is the performance, in which the emulator then finally runs. :) But understandable, that one single UI is alot easier to maintain for the programmers.


    Seems like the problem in the combination of GTK3 and Windows, that causes this stuttering-problems, was finally found and wiped out now and when it was necessary, that patches for GTK must have been submitted to make this possible,

    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.

    then it's even better. Maybe also other projects in the future which also uses GTK, could have a profit from this then? Now this seems to work like it should on nearly all Windows machine. Good work, cause now this port is finally usable for gaming and watching demos.



    But "Zirias", i can't avoid asking (and i dont mean it in bad way) ;) - when this stuttering-problem had nothing to do with the combination of GTK3 and Windows at all, like you always wrote before, why patches must have been submitted for GTK now, to make this work in a good way on Windows machines then? :)

  • that patches for GTK must have been submitted to make this possible

    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.

  • 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.


    Definitely superb, that this stuttering-problem could finally be wiped out on Windows machine. Thanks to all people involved solving it. Now i hope all similar problems on Mac machines can also be solved, even when i don't own one. What the GTK people said, why they can not accept all patches?

  • AW182 I never claimed GTK would be free of any bugs or issues, I just always said the move to maintain only one UI frontend was a sensible one. In the long run, this will pay off. So why did it have to be GTK? I can only speculate, most probably because VICE wants to keep the code "plain" C. With C++, Qt or maybe wxwidgets would come to mind (without claiming they wouldn't have issues, I prefer Qt for UI frontends, but I don't write any timing-critical software so far) – but if you want to code in C, there's as far as I know only one choice for a cross-platform UI toolkit, and that's GTK.


    So, if VICE will be one project that ultimately improves GTK, that's certainly not a bad thing. The time spent to do this will benefit other projects as well. I rest my case, moving to a single UI frontend for all platforms was a good and sensible move. And I still feel bitter about people just mixing up anything, getting rude at VICE coders for doing this, without even understanding the reasons and how this will improve the quality (over ALL platforms, remind you, Windows is not the center of the world) in the long run.

  • AW182 I never claimed GTK would be free of any bugs or issues, I just always said the move to maintain only one UI frontend was a sensible one.


    But it's true to say, that you always claimed, that this stuttering-problem has definitaly nothing to do with GTK and that all people which said that it maybe could have, absolutely have no idea, right? :) Not that i want to start the next discussion, but things should be said like they were, i think. Finally it seems, that it had something to do with it and now patches was made for GTK, to prevent problems like this under Windows operating-system.


    Now, that this big stutter-problem seems to be gone forever in the GTK3 version, users can concentrate on learning the new look of the menue and getting used to this version, cause they have a similar performance now in this version, compared to the older, native WinVICE builds. Playing games now is possible and watching demos also. The complaining about the stutter and bad performance will now go away, but that there was a complaining about this stutter-thing before, was normal. The problem was too big before, just to overlook it. It has determined the handling with the GTK version so far and the version was not fully usable on alot of Windows PC's until now.


    But this seems to be over now and no more discussion about the old things necessary, i think. Nevertheless, when discussions in different forums maybe can push things, then they were justified in the end and i am sure, when no users at all would have said a word about this stutter-problem, it would still be there in the GTK version and nobody would have worked on it. Therefore i think it makes sense to make discussions and i also think, that a kind of competition between the different C64 emulators which is there a little bit, also is very good for the future development of each of these emulators. Pushing each other forward, which different emulators do when they are in competition, even if it's not directly intended, is a good way to get more improvements and better and better performance in all these emulators. I think, it's a good thing. :)

  • you always claimed, that this stuttering-problem has definitaly nothing to do with GTK

    No. I never experienced it on my only Windows machine (the MS Surface book from work), and I said it may depend on how redering is done, with respect to the drivers' capabilities on the target system. What I always opposed to were these witch-hunt threads with people hating the move to a GTK frontend for all sorts of reasons (and some not even understanding what this means), mixed with a lot of "it's different than before" whining. I never claimed GTK would be free of any bugs. What I said is that moving the UI to GTK for all platforms can't be the reason for any rendering issues observed. So, if improving this really requires changes to GTK, that would be a surprise (and I'd like to see some related bug report). But reading Compyx' OP, I still think that isn't the case at all. Now please prove me wrong, if you can.

  • Now please prove me wrong, if you can.


    If you want, sure. Let's look at all your statements to the stuttering-problem:


    Zirias wrote:

    Soviel war schon eindeutig geklärt, dass das mit GTK genau gar nichts zu tun hat (sondern mit Bildwiederholraten die sehr nahe beieinanderliegen, bei denen der Sync-Code im aktuellen Vice nicht ideal arbeitet) -- ebensowenig wie mit dem Betriebssystem, auf dem Vice läuft.


    Zirias wrote:

    Even if there's another source of problems (shitty resolution of Windows' timers), this still has *nothing* to do with GTK.


    Zirias wrote:

    Auch wenn ich (und manche andere) keinerlei Probleme nachvollziehen kann, egal ob nun auf Windows oder auf anderen Plattformen -- ich bestreite doch nicht, dass es welche gibt. Das ist ja durchaus möglich. Nur kann ich dir versichern (und darauf würde ich eine Menge wetten), dass das nichts, aber auch GAR nichts, mit GTK zu tun hat.


    Zirias wrote:

    Was auch immer man an -- nennen wir es mal "Performance" -- Problemen beobachtet: das hat mit an Sicherheit grenzender Wahrscheinlichkeit nichts mit GTK zu tun.


    Zirias wrote:

    Der Knackpunkt ist und bleibt: Die Ursachen der Probleme haben nichts mit GTK zu tun.


    Zirias wrote:

    Das "Problem" mag bei der großen Umstellung entstanden sein. GTK ist dafür NICHT ursächlich.


    Zirias wrote:

    Und ja, blöd wenn man (auf manchen Systemen) in Performance-Probleme läuft. Das sollte aber ein lösbares Problem sein. Es ist einfach technisch ausgeschlossen, dass GTK hier ursächlich ist.


    Zirias wrote:

    Ist halt so. GTK kann nicht die Ursache sein. Die große Umstellung zu 3.x natürlich sehr wohl.




    Letztendlich waren dann, wie wir ja jetzt hier lesen konnten, Patches für GTK nötig um es hinzubekommen und es hatte dann also doch mit einem Problem, entstanden aus der Kombination GTK3 und Windows, zutun. Hätte es nichts mit GTK zutun gehabt, warum waren hier jetzt dann Patches an GTK nötig, um hier dann endlich auf eine gute Performance zu kommen?

  • Mir persönlich ist es letztlich *egal* was die Ursache für das Stottern war. Wichtig ist: Es ist behoben.

    "Problem" war bei mir immer: Ich wollte mich nicht an eine andere GUI gewöhnen, solang die Emulation einfach schlecht lief.


    Wenn alles super läuft, kann man sich auch mit der GUI beschäftigen, die nach Ersteinrichtung meist wohl eh nur noch zum Laden von Software genutzt wird.


    Wenn jetzt noch die Sache mit dem Lock auf 50.000hz Mode klappen würde, dass auch der Microruckler wegen des Frameskips alle 8 Sekunden wegfallen würde - ein Traum.


    ... und jaaaaa dann immernoch mein innig geliebter Wunsch nach Pseudo-Stereo.... Das wär's...

  • The primary cause of stuttering 'Ruckeln' was that VICE code was running entirely within a single threaded GTK application. This means that whenever GTK / GDK was doing or waiting for a host system operation (rendering for example), VICE was not running. Block vice long enough and you get missed frames and audio glitches. On Linux this seemed to generally work OK, except when opening dialogs you'd hear weird sound glitches and see frames drop. On Windows it was a lot worse, even moving the window would cause gltiches. On macOS it was worse again and had terrible rendering bugs when resizing the window.


    Things I have done:


    • Place VICE in its own thread of execution so that its timing does not depend on what GTK happens to be doing, so long as there are at least CPU 2 cores. This is the necessary foundation for all stutter removal work and by itself yielded a huge improvement. Of course, synchronising access to VICE data structure between multiple threads is not trivial and significant work was required here, work that is not yet complete. The reason that dialogs other than the settings dialog still cause stutter is that by default all GTK event handlers are holding a core VICE lock while executing. On a case by case basis I am converting these so that they do not need to hold the VICE lock for safety. I have done this for the settings dialog, but not for others, yet.
    • GDK was incorrectly detecting OpenGL extensions with the result that the GTK OpenGL integration wasn't using a high performance path on macOS, and probably on some other systems depending on the installed OpenGL driver. Specifically, the OpenGL standard does not require that extensions be listed in the extension strings in the case where an extension is promoted to a core OpenGL profile. This patch was accepted: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1424
    • The above brought VICE GTK OpenGL performance into a pretty good place on all platforms, but in a profiler I noticed that GTK wastes a LOT of time allocating & zeroing a temporary bitmap surface used to get the offscreen OpenGL render result and mix it in with other GTK elements. The fix is simple - reuse the buffer. Unfortunately this patch has not been accepted, primarily due to the reviewer seemingly not understanding it: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1441

    The above represents the work in my threaded-ui-exp branch. Then, a couple of weeks ago, I grew frustrated that we were still depending on GTK/GDK to render to the screen for us. Even with my patch accepted this will still not yield ideal performance because GTK needs to render to an offscreen buffer, pull the result back to the host memory and then slowly blend it with other GTK widget UI before sending back to the GPU. So I set out to set us free from that and the test Windows builds in this thread area the first result we've shared from that effort.

    • Instead of relying on GtkGlArea for rendering, I added a native child window to the application using the old native win32 API and wrote a simple Direct2D(DirectX) renderer to get our emulated screen rendered on it with hardware acceleration.
    • Decoupled host rendering from VICE rendering, so that a third thread now deals with the host graphics API, waits for vsync, etc.

    I think the result is very good, so I've begun work to do a similar conversion for macOS and Linux. These platforms will still use OpenGL but will use a native child window as well. I initially intended to use Metal on macOS but this would mean dropping support for some perfectly good macs that can handle OpenGL just fine. So i'll start with OpenGL so that we retain our compatibility for all macs running macOS 10.9+. Once all platforms are rendering using the new architecture we'll merge to trunk and clean up the remaining dialog glitches and cases where VICE code invokes GDK/GTK code directly (which can cause crashes, depending on timing).


    The overall situation is nicely balanced this way - per platform rendering code for performance, but shared UI code for the host application for our productivity.


    In future, I intend to spend some time on the audio code to make sure we're doing the best we can there, in particular getting latency down where it's high. Windows audio can get strange after warp too, which I aim to fix. As for exact 50/60/whatever Hz clocking, can look at that later but the current focus is on getting the above right. An option for setting host display res/refresh rates is not out of the question but again I personally won't be looking at that at the moment.

  • AW182 Diese sinnlose Ansammlung von Zitaten schiebe ich mal auf mangelndes Verständnis des englischen Textes, also gerne nochmal eine Erklärung auf deutsch: Das "No" war keine vollständige Verneinung, sondern eine Zurückweisung deiner äußerst plakativen Aussage. Nach wie vor ist es so, dass für irgendwelche "Ruckel-Probleme" NICHT Code in GTK selbst ursächlich war, wie man eigentlich schon an dem OP dieses Threads ablesen kann. Dass im Zuge der Entwicklung von VICE trotzdem Änderungswünsche an GTK selbst entstehen oder Bugs darin gefunden werden, steht auf einem anderen Blatt. "Now please prove me wrong, if you can." bezog sich auf DIESE Aussage. Du kannst ja gerne auch direkt bei VICE Entwicklern nachfragen. So, genug Text erklärt…

  • Just wanted to add that all the changes outlined in my previous post are not yet merged into the official VICE SVN repository. Many, many changes will be made before the merge and therefore it is not worth anyone's time to build feature patches against it as has been suggested by AW182 in another thread. We will look at fixed 50/60/whatever Hz support when the time is right.

  • AW182 Diese sinnlose Ansammlung von Zitaten schiebe ich mal auf mangelndes Verständnis des englischen Textes


    Ah ich sehe schon, deine anmassende Arroganz scheint nach wie vor ungebrochen zu sein. Jetzt lag's also auf einmal an meinem Englisch *lol*. Aber glaub mir mein Freund, mein Englisch ist mit Sicherheit 10mal besser als deines, fast fliessend. Ich hab mehrere Jahre in englischsprachigen Ländern verbracht, also komm jetzt nicht mit solchem Quatsch daher, nur weil du falsch lagst mit deiner Beurteilung, dass GTK nichts mit der Ruckelproblematik zu tun hatte.


    Du solltest dich vielmehr an deine eigenen Worte halten, wie etwa an die hier aus dem VICE V3.4 Thread:




    Zirias wrote:

    Der Knackpunkt ist und bleibt: Die Ursachen der Probleme haben nichts mit GTK zu tun. Dir würde ein Zacken aus der Krone fallen, jemals eine Fehleinschätzung, trotz völliger Ahnungslosigkeit, zuzugeben.




    Aber wie man sieht, bist du selbst am meisten von genau diesem Problem betroffen, Fehler nicht zugeben zu können. Wer im Glashaus sitzt, soll nicht mit Steinen werfen. Ein altes Sprichwort, hast du vielleicht schonmal gehört? :) Dass diese Ruckelproblematik nichts mit GTK zu tun hatte, war nunmal nichts anderes als eine Fehleinschätzung. Es hatte nun eben doch mit GTK zu tun und Patches daran waren notwendig, ohne die es nunmal nicht funktioniert hätte. Eindeutiger geht's ja kaum. Wie kann man bei dieser Faktenlage immernoch den Standpunkt vertreten, es hätte nichts damit zu tun gehabt?


    Nach wie vor ist es so, dass für irgendwelche "Ruckel-Probleme" NICHT Code in GTK selbst ursächlich war, wie man eigentlich schon an dem OP dieses Threads ablesen kann. Dass im Zuge der Entwicklung von VICE trotzdem Änderungswünsche an GTK selbst entstehen oder Bugs darin gefunden werden, steht auf einem anderen Blatt. "Now please prove me wrong, if you can." bezog sich auf DIESE Aussage. Du kannst ja gerne auch direkt bei VICE Entwicklern nachfragen. So, genug Text erklärt…

    Änderungswünsche an GTK? *lol*. Interessant ausgedrückt in diesem Fall, nachdem es vorher damit monatelang nicht funktioniert hat, das massive Ruckeln im GTK-VICE wegzubekommen. Warum diese Verharmlosung? Fakt ist nunmal, und das kannst du jetzt im Nachhinein versuchen schönzureden wie du willst, dass eine ruckelfreie Darstellung im Emulator in der Kombination GTK3 und Windows vorher so nicht möglich war und mehrere Patches dafür eingereicht werden mussten, das siehst du doch selbst inzwischen. Warum jetzt also noch versuchen, das schönreden zu wollen im Nachhinein, wo es eh alle schon wissen?


    Dass es monatelang diese Ruckelprobleme im GTK3-VICE gab, lag an GTK. Im SDL2 VICE hatte man nie mit derlei Schwierigkeiten zu kämpfen und das Scrolling dort war von Anfang an genausogut wie in der nativen WinVICE Version.



    Natürlich ist es im Nachhinein so wie "Hagtrix" hier schreibt

    Mir persönlich ist es letztlich *egal* was die Ursache für das Stottern war. Wichtig ist: Es ist behoben.

    und worauf es ankommt ist jetzt letztendlich, dass dieses Ruckeln nun verschwunden ist. Aber Wahrheit sollte schon Wahrheit bleiben und man sollte nicht versuchen, sie im Nachhinein zu verdrehen, "Ziriax". GTK, bevor es Patches dafür gab, war der Hauptgrund für die monatelangen Scherereien mit dieser massiven Ruckelei, die nun aber zum Glück beendet ist.