Re: [hatari-devel] OS X performance problem

[Anders Eriksson <ae@xxxxxx>]

On Thu, 29 May 2014, Eero Tamminen wrote:

> Ok, this is Sandy Bridge.  Do you have 1600Mhz DDR3 memories
> or something slower?

It is 1333 MHz DDR3. The machine is getting a little bit old, but 
still holds up fine to everything I throw at it, except the Hatari 
diskdrive led indicator ;-)


> Is your issue in windowed or fullscreen mode?

I ony run Hatari in a window, as the fullscreen doesn't play nice (OS X 
virtual desktops stop working while Hatari is in fullscreen). It would be 
so good if it had OS X native fullscreen instead, so the app would just 
create it's own virtual desktop screen, like other OS X apps. But I know, SDL 
doesn't support it.


> What you calculated, is Hatari part of the operations.  Then there
> are operations that SDL OSX backend does, and the OSX desktop compositor.

Yes, although everything else is smooth as butt so I imagine things are 
normally using OpenGL for all that. For example, throwing up 1080p or even 
1440p movies with VLC in a window is no issue, not a frame drop and the 
datarate from that wastly overshadows Hatari. But again, that's 
not SDL.



> [1] If you aren't running other applications besides Hatari,
> I think we can be pretty sure that rest of the system hasn't
> caused graphics card to run out of memory. :-)

Well the entire UI is OpenGL so it's using a lot of memory, and the screen 
is 2536x1440 that eats up some bandwidth by the displayport as well.


> I would assume OSX desktop side to be done sensibly, so
> my suspicion is that SDL 2D backend does something really
> braindead on OSX, in addition to turning every UpdateRect(s)
> call to window update.

I dug up an old message from the Hatari mail list (from 2008) when this 
topic was discussed, the painting program Grafx2 had some serious 
perfomance issues, SDL based just like Hatari, this is what they found 
out:

"Ok, here's the deal: under macosx SDL_UpdateRect() automatically waits
for vblank so calling it for each pixels drawn isn't a good idea at all.
What i did is to remove all those updates calls for macosx and just use
one in Get_Input()."

So if there are two calls to UpdateRect, it would use 2 vbl. If the status 
bar indeed does that, then it's pretty clear that there will be slowdown. 
Maybe this has been fixed in SDL since then though. After all that was six 
years ago.



> > But I don't know how Hatari works, maybe it updates the window many many
> > times per refresh and thereby exceeds the bandwidth as you suggest. Or
> > maybe I did the calculations all wrong :)
>
> You just left out most of the operations. :-)

Yes the internal OS ones, but taking another app that throws a lot more 
pixels around will be smooth, such as the high-res movie playing I 
mentioned above.



> However, as you calculated, at Hatari window sizes and the memory
> speeds of current machines even doing it on CPU side shouldn't be
> a problem, *unless* something stupid happens between what Hatari
> does and its output ending on screen.

Exactly, and that's what I've been trying to tell for the last six years 
:) It's a bit funny, because if you run Hatari in a Linux-VM it won't 
suffer from these problems.

--
Anders Eriksson
ae@xxxxxx     http://www.dhs.nu/
ae@xxxxxxxxx  http://www.atari.org/