| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
VICE threaded UI test builds
In this thread i will post test builds of the (hopefully) soon to be merged threaded ui rewrite.
Linux and OSX users can always grab the current state from dqh's git repo here: https://github.com/dqh-github/vice-experiments/tree/threaded-ui.. (make sure to checkout the "threaded-ui-exp" branch after cloning the repo)
Please test and report back positive and negative results. Especially interesting right now are rendering errors/problems and unexpected crashes. Please tell exactly what OS you are using, and what GPU.
I will keep posting new windows builds here - starting with todays: https://sourceforge.net/projects/vice-emu/files/experimental%20..
64bit only right now - i'll have to figure out how to build proper 32bit binaries on my box (not that you should be still using a 32bit OS in 2020). |
|
... 149 posts hidden. Click here to view all posts....
|
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
Happy to see it run very smooth on Win10, I've been using offensively old VICE versions for a long time. Only thing I noticed was that sometimes after startup and loading a disk, audio latency was high (> 1 sec). This got fixed by fiddling with the sound buffering settings, now have smallest fragment size and "adjusting" sync method, and the high latency hasn't reappeared so far. |
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
I started messing with the mouse problems. The wrap problem is due to that gtk_warp_device always is relative to the considered default monitor for the screen. I’ve fixed that and compensated properly. So capture of the mouse now works properly. There are still problems getting relative coords though, the motion callback is triggered but the calculated deltas are 0,0 unless I move exceptionallly fast. I assume this is due to deltas are calculated after pixel scale compensation which is plain wrong. I’ll fix that also. |
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Also thinking if it wouldn’t be better to hook into the usbhid layer directly instead and get relative hw-coords right away... this warping of the pointer feels utterly ugly |
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Quote: I started messing with the mouse problems. The wrap problem is due to that gtk_warp_device always is relative to the considered default monitor for the screen. I’ve fixed that and compensated properly. So capture of the mouse now works properly. There are still problems getting relative coords though, the motion callback is triggered but the calculated deltas are 0,0 unless I move exceptionallly fast. I assume this is due to deltas are calculated after pixel scale compensation which is plain wrong. I’ll fix that also.
Further debugging reveals that after a pointer warp gtk will report motion, but not updated coords for about 200ms, causing everyrthing to fuck up. Digging further into the gtk/gdk sources to see why this behavious exists and possible ways to prevent it.
Recent gtk doesn't event support pointer warp anymore and the APIs have been removed alltogether so I suppose a more direct way of getting relative mouse motion is needed to be future safe. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
aaaaarg. another thing we need to solve with archdep code? SATAN! |
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Quote: aaaaarg. another thing we need to solve with archdep code? SATAN!
Yup.. |
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Quote: aaaaarg. another thing we need to solve with archdep code? SATAN!
Should consider libusb for input handling. That would make hid-input portable. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11164 |
i already hate that idea :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1997 |
Quote: i already hate that idea :)
Not keen either tbh, but it actually offers a thin HID-wrapper which means that joysticks, keypads and relative mouse could be handled in a uniform way. Keyboard and light pen could and should still be handled by gtk.
But the rewrite would be massive and nobody will do it. :) |
| |
dqh
Account closed
Registered: Jun 2019
Posts: 46 |
cadaver - thanks for the report. Once I’m finished playing with rendering performance I’m going to shift my focus to audio (all platforms). I think audio is the last major source of performance glitches, depending on the sync method and driver. |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 - Next |
