| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
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 |
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: 1989 |
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: 1989 |
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: 444 |
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. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Found another problem.trace load $dc01
causeslocking: "configure-event"[G_CALLBACK(on_window_configure_event)]
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!)
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
Error: lib_debug_alloc(): Out of debug address slots. (increase LIB_DEBUG_SIZE!)
Error: lib_debug_guard_add(): Out of debug address slots. (increase LIB_DEBUG_SIZE)
uimon.c:160: Error: lib_debug_guard_size(): Cannot find debug address 0x7f1bf003a350!
uimon.c:160: Error: lib_debug_guard_remove(): Cannot find debug address 0x7f1bf003a350! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
i like how basically our own code says its broken =D |
| |
spider-j
Registered: Oct 2004
Posts: 444 |
I get the same "CRT controls" glitch on my laptop. It's pretty much the same system regarding software.
Intel i5-7200U, HD Graphics 620, Gnome 3 via xorg-server
Kernel 5.6.13-arch1-1, mesa 20.0.7-2, gtk3 1:3.24.20-1, gnome-desktop 1:3.36.2-1, xorg-server 1.20.8-2
By the way: the controls don't seem to be the same as in trunk. So it could be this glitch did exist in trunk at some point in the past and it's here because the current state isn't in the github repo? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 16 - Next |
