<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Severe performance degradation on a macOS with 10-bit displays" href="https://bugs.documentfoundation.org/show_bug.cgi?id=137468#c33">Comment # 33</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Severe performance degradation on a macOS with 10-bit displays" href="https://bugs.documentfoundation.org/show_bug.cgi?id=137468">bug 137468</a> from <a class="email" href="mailto:ilford@gmail.com" title="Leo Wang <ilford@gmail.com>"> Leo Wang</a> <pre>(In reply to Tor Lillqvist from <a href="show_bug.cgi?id=137468#c32">comment #32</a>) > > I think the test needs to be improved so that it is aware of the color value shift due to the nature of color space difference. > > Maybe, but surely also other code all over the place (slight exaggeration) > would need to be adjusted, too, if the colour space used to display LO's > windows were a device-dependent, potentially wide gamut, colour space. As it > is (now with the change reverted), everything is sRGB. Currently the test unit creates a bitmap, draws a point with specific color, gets the pixel's color value and compares against the original value. This only works when there is only one color space. Maybe we can add a "hidden" preference item to let the user choose? Without a complete rewrite of the renderer, it is very difficult to make use of the GPU: all bitmap drawing works have to be done with CPU, and it is hard to predict what color space CGLayer determines to blend all the layers to generate the final bitmap. PS: with all the 3 patches to "consistentize" the color spaces, on my Mac LibreOffice retrieves 20-25fps for text, spreadsheets and simple presentations.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>