Re: [hatari-devel] OS X performance problem |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On May 28, 2014, at 5:46 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
>
> To see what compiler options CMake uses. If there's no -Ox option,
> that explains the slowness.
I saw -O3 instead of -Ox. Would this make a huge difference? Or do you simply mean a number after the “-O”?
>
>
>> Something dealing with screen refresh ??
>
> Try "--statusbar=no --drive-led=no" to see whether these
> affect the screen update.
>
This solved the problem for me. Shutting off the status bar brought Hatari back up to full speed. Since the status bar was never a problem before, I am wondering if it is the track information that is being constantly displayed. I do not know what else has been changed in the status bar that would have such a drastic effect. The other new information is very static (do you have a joystick plugged in?).
Unlike Jerome, I am using the OS X GUI that is in Mercurial. With that interface, I was able to use the OS X menu items without Hatari without a problem. Occasionally, selecting a disk through the OS X file selector would bring up the SPOD (think GEM busy bee cursor). However, that was not consistent and the function did work after 1-3 seconds.
@Nicolas - Is there any way to disable the track information without affecting the rest of the status bar? I do miss the LED lights and the fast forward indicator along with my current TOS version.
Thanks everyone for the suggestions. I was very discouraged yesterday that an OS X binary might not be possible. I feel better about it today.
Bob C