Performance impact on 10-bit displays

I am using FRV on my Mac Pro with a 10-bit 5K display (LG UltraFine 5K). When FRV window size is large (near full screen), the performance of scrolling the image list window becomes very poor. There is even an obvious delay I hover the mouse pointer from one thumbnail to another.
 
I found this may be related to the color depth. If I set the color profile to RGB (sRGB IEC61966-2.1), the scrolling performance will be quite good.
 
I can reproduce this problem on my Mac Pro (10.15.3) and iMac Pro (10.14.6, with the internal 5K 10-bit display).
 
Please let me know what I can do. Thanks.

Thanks for the reply.
 
I tried the compatibility version, it is a little bit faster but ICC seems not applied.
 
I used iStat Menu to watch GPU framerate.
 
Original version: 8bit=19.5fps, 10bit=5.7fps
Compatibility version: 8bit=19.5fps, 10bit=6.7fps

Thank you for additional data (fps numbers).

It looks like screen color conversion on macOS may be slow (it is CPU based), so the only way is to bypass it.



We'll prepare modified version (with colorsync always bypassed) in a few days, we'll contact you when we'll have something to test.

Yes you are correct. I just ran Instruments on the Mac Pro. The hottest spot is CGColorTransformConvertUsingCMSConverter in macOS 10.15.3.

The color conversion is necessary IMO, without proper conversion, the display will be over-saturated, just like switching a 10bit display to 8bit RGB.

Can you cache the converted thumbnail bitmaps so that the big window content doesn't have to be updated as a whole?

Thanks.

Could you please E-mail Instruments() output (with full stack above CGColorTransformConvertUsingCMSConverter expanded) to support@fastrawviewer.com ?  Right now we're unable to reproduce slow-down you experience (also 10-bit display, but on 4k screen), so this report may help us a lot.



We already cache thumbnails (color converted to display space if 'Color space for thumbnails' is not set to 'Not color managed' in preferences).

After that entire window (subwindow, to be precice) is converted by macOS from 'window' color space to 'display'

(this is different for single image view: for single image we bypass this conversion by using direct OpenGL draw)



The GUI toolkit we use creates window with SRGB color space assigned. This is a non-issue for 8-bit output because 8-8 bit conversion is fast. The only way is to bypass conversion (instructing macOS that the window is already in destination color space)

 

I have sent the picture. Please check.

Received, thank you.

Add new comment