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)
Could you please E-mail
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)
--
Alex Tutubalin/FastRawViewer team