Slow under macOS about rust_minifb HOT 12 CLOSED

Hum... I'm not sure why this would be the case. I pretty much only use system/API calls to draw this in here https://github.com/emoon/rust_minifb/blob/master/src/native/macosx/OSXWindowFrameView.m#L25

I figured that this would be pretty fast but maybe that isn't.

from rust_minifb.

I'm not super comfortable with OS X (despite using it as a dev platform...) but I'll see if I can investigate this with a profiler.

from rust_minifb.

Using Instruments (that comes with XCode) should be able to trace down into the calls of a running process so that will likely give a hint on whats going on but I suspect some of the operations I would think should be on the GPU happens on the CPU instead (like the scaling)

from rust_minifb.

This is an old flamegraph I made while testing performance with minifb : https://github.com/jedahan/rustboy/blob/master/pretty-graph.svg might be some help, might not.

from rust_minifb.

It seems the majority of time in update_with_framebuffer is argb32_image_mark_rgb24, which from this stack overflow is kinda slow http://stackoverflow.com/questions/21665473/coregraphics-argb32-image-mark-rgb24-is-slow . Maybe there is a way to create a 32-bit context so no conversion is needed.

from rust_minifb.

And a possible solution from http://stackoverflow.com/questions/33075557/avoiding-colorspace-transformations-when-blitting-mac-os-x-10-11-sdk#33076871

colorSpace = ::CGDisplayCopyColorSpace(::CGMainDisplayID());

if (!colorSpace)
    colorSpace = CGColorSpaceCreateDeviceRGB();

from rust_minifb.

In that benchmark from above, I got a ~25% total speedup, from average 44ms to 33ms with that patchset. Tested on my (retina) MacBookPro12,1.

from rust_minifb.

Following this post http://carol-nichols.com/2015/12/09/rust-profiling-on-osx-cpu-time/ , here are the flamegraphs with and without the change:

https://github.com/jedahan/scrap/blob/master/slow.svg

https://github.com/jedahan/scrap/blob/master/fast.svg

Theres a bit of a speedup, but argb32_image_mark_argb32 is still the slowest function...

from rust_minifb.

Thanks for the info. Yeah I wonder what that argb32_image_mark_argb32 is doing.

from rust_minifb.

Maybe it's actually doing the scaling inside this function (instead of actually doing it on GPU which would be 0 ms CPU time and very fast)

from rust_minifb.

To me it seems like the only way to get around it would be to implement this in OpenGL or Metal :/ Unless someone has a better idea.

from rust_minifb.

Hi, I have now rewritten the macOS backend to use Metal instead which should make this a lot faster. If you are still using minifb it would be great to hear if this improves things for you or not. I will close this for now but if it doesn't help please re-open this again

from rust_minifb.