Re: [hatari-devel] OS X performance problem

[Jérôme Vernet <vernet.jerome@xxxxxxxxxx>]

One thing wich is possible: making a native cocoa status windows. It's just a matter of changing Cocoa GUI properties and let osx thread drawing things.
I made it a while back for drive led.

If there is only one place where sdl status bar is drawn it's easy to do.

Envoyé de mon iPhone

> Le 1 juin 2014 à 10:01, Eero Tamminen <oak@xxxxxxxxxxxxxx> a écrit :
> 
> Hi,
> 
>> On sunnuntai 01 kesäkuu 2014, Bob Carpenter wrote:
>> I decided to load the PD game Frantick with its 640K music track into
>> memory from floppy disk. I thought that would be a good bench test since
>> it has to read the floppy disk for a long time before the startup screen
>> appears. Back in 1995, the author recommended loading it on a hard disk
>> if you were going to use the music track.
>> 
>> Anyway, here are the numbers:
>> 
>> In fast forward mode:
>> 1.7 devel version (no track information) - 21 seconds
>> 1.8 devel version (track information) - 58 seconds
> 
> Do you see same difference also with statusbar disabled
> (--statusbar off)?
> 
> * If you still see the difference, it's not because of statusbar,
>  but something else, most likely Nicolas' FDC emulation improvements.
> 
> * If difference disappears with statusbar, then the slowdown is
>  due to statusbar and needs to be looked into.
> 
> 
>    - Eero
> 
>> In real time mode:
>> Both 1.7 devel and 1.8 devel finished in 4 minutes 57 seconds
>> 
>> I do not know of many ST programs that accessed the disk during gameplay.
>> Back when I had my 1040 with only a floppy drive, I would have thrown
>> the disk across the room if it was accessing the disk while I was trying
>> to play the game. Obviously, some games access the disk between levels
>> (Zany Golf comes to my mind). If a game or demo was accessing the disk
>> while running, I could see how the track information could slow things
>> down. I just do not have examples of programs that are running and
>> accessing the disk at the same time.
>> 
>> If you are only updating the information when it actually changes, I do
>> not see how you can really improve this. The only other option would be
>> to make the track information display optional. That way, OS X users
>> that had problems with it could turn it off and they would be no worse
>> than if they ran 1.7.
>> 
>> 
>> Bob C
>> 
>>> On May 31, 2014, at 5:11 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
>>>> On lauantai 31 toukokuu 2014, Bob Carpenter wrote:
>>>> I have only started using the devel version with the changes you made.
>>>> It is running fine. I did not see any improved performance, but the
>>>> performance was fine on Hatari with the previous version. Your
>>>> changes may very well help users with older Macs though.
>>> 
>>> It's not related to how slow machine you have, but what you're
>>> testing.
>>> 
>>> First fix I did was to do statusbar updates only when something
>>> changes.  Now I fixed the case where statusbar actually changes.
>>> 
>>> I.e. you need a test case that causes constant updates to
>>> statusbar state, something that does constant disk accesses.
>>> 
>>>    - Eero
> 
> 
>