Re: [hatari-devel] OS X performance problem

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 01 kesäkuu 2014, Jérôme Vernet wrote:
> 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.

It's drawn from statusbar.c, from several functions in it.
You can find these functions by searching for "SDL_Surface".


	- Eero

> 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