| |
chatGPZ
Registered: Dec 2001
Posts: 11107 |
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....
|
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsserI can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup.
You could build in Xcode and run it in the Xcode debugger - there's doc on how to do it in in doc/building. |
| |
JackAsser
Registered: Jun 2002
Posts: 1988 |
Quote: Quoting JackAsserI can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup.
You could build in Xcode and run it in the Xcode debugger - there's doc on how to do it in in doc/building.
It now works, I had forgotten the initial make install. Thought it wasn't needed since I build my VICE all the time and install them. Will test performance and reports bugs now. :) |
| |
JackAsser
Registered: Jun 2002
Posts: 1988 |
Works alot better now. CPU usage is on part with the SDL2-build and the jerky motion is much less severe now. It's what you can expect running 50Hz stuff on a 60Hz screen.
The first bug that I encounter is that rescaling the main window is completly wonked here and entering fullscreen makes me only see the lower left portion of the emulator screen, and zoomed about 2x too much.
Moving the main window between external displays also produce different (and wrong) scaling.
However, good work still!! Keep it up! I'm eager to switch to a proper GTK-build once the initial bugs are solved (and mouse grabbing and 1351 support actually works). |
| |
dqh
Registered: Jun 2019
Posts: 46 |
The resizing bug is actually in GTK3 macOS itself - i've replicated it in their GtkGlArea example. In all likelihood i'll have to fix that bug myself.
For me though, going fullscreen always sorts it out, and returning from fullscreen also. Sounds like that's not the case for you. What hardware are you testing on - are you using a retina display? |
| |
JackAsser
Registered: Jun 2002
Posts: 1988 |
Quote: The resizing bug is actually in GTK3 macOS itself - i've replicated it in their GtkGlArea example. In all likelihood i'll have to fix that bug myself.
For me though, going fullscreen always sorts it out, and returning from fullscreen also. Sounds like that's not the case for you. What hardware are you testing on - are you using a retina display?
Yes, I'm using Retina. Was my first suspicion also, that in didn't handle pixel scale property (2x pixels)
MacBook Pro (15-inch, 2018)
Processor: 2,9 GHz 6-Core Intel Core i)
Memory: 16 GB 2400 MHz DDR4
Graphics: Radeon Pro 560X 4GB + Intel UHD Graphicvs 630 1536 MB |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Interesting, i'm using a retina laptop with a regular external screen. I see the same types of fuckery except that switching to or from fullscreen always fixes. I expect that the same bugfix will apply to all these cases. |
| |
JackAsser
Registered: Jun 2002
Posts: 1988 |
Quote: Interesting, i'm using a retina laptop with a regular external screen. I see the same types of fuckery except that switching to or from fullscreen always fixes. I expect that the same bugfix will apply to all these cases.
Yeah. Let's wait and see until you've applied your own bugfix to this. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting spider-jClicking on "CRT controls" occasionally just shows thin borderlines and the content from the windows / desktop below
Didn't happen with the "Mixer controls" switch so far.
Weird, on my box (Debian 10.3 with Cinnamon, i5-7400 + nvidia 1060GTX 3GB) that works fine with both trunk and dqh's branch.
I recently did some work on the CRT sliders, reducing vertical space by using two columns and using larger negative margins for the sliders (yay Gtk).
Does this also happen with trunk? |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Now it compiles and i can put some command in monitor window...
But...
If i try a "chis", x64sc freezes and i can only kill him.
"chis 50" or "chis 100" works, but using a value ">189" seems to make x64sc crash.
(I have always used the command without parameters but, since it crashes, i have tried with a value to understand what happened.)
I compiled with ./configure --enable-native-gtk3ui --enable-static-ffmpeg --enable-cpuhistory --enable-new8580filter --enable-x64 --enable-debug
I don't know if this is directly related to this version... but that's it.
(the rest seems to work well ... at least as far as I've tried) |
| |
spider-j
Registered: Oct 2004
Posts: 443 |
Quote: Quoting spider-jClicking on "CRT controls" occasionally just shows thin borderlines and the content from the windows / desktop below
Didn't happen with the "Mixer controls" switch so far.
Weird, on my box (Debian 10.3 with Cinnamon, i5-7400 + nvidia 1060GTX 3GB) that works fine with both trunk and dqh's branch.
I recently did some work on the CRT sliders, reducing vertical space by using two columns and using larger negative margins for the sliders (yay Gtk).
Does this also happen with trunk?
Nope, doesn't seem to happen with trunk here. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 17 - Next |
