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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/