Description: Rotating a raster image 90 degree left/right with right click context menu doesn't instantly paint on screen Steps to Reproduce: 1. Open the attached file 2. Right click the top left image 3. Select Rotate or flip -> Rotate 90 degrees -> nothing appears to happen 4. Defocus the LibreOffice window or double click the an image -> screen gets updated Actual Results: Nothing appears to happen, using Skia/Raster or Skia/Metal. Possibly Mac specific, didn't test Windows Expected Results: Instant refresh Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 5e0c670e6534fee529ea46d520c6b442bea93aac CPU threads: 8; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 197815 [details] Example file
Hi Telesto, I could reproduce and also noticed another behavior in both version 24.8.2.1 and 25.2.0.0. 1. Open the attached file 2. Right click the top left image 3. Select Rotate or flip -> Rotate 90 degrees -> nothing appears to happen 4. Right click the top right image 5. Select Rotate of flip -> Rotate 90 degrees 6. Both images rotate right at the same time I have updated the status to NEW. Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ce4ae4f082d8fe80da242836c57d55a456eac5e0 CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
@Regina I have no idea what's going on here. The images in the example file have a delayed execution or painting on screen when rotating. Apparently a thing for years (at least also in 7.0.0.3) However there are cases where it simply works, like attachment 184430 [details]
I see the problem still in Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 7c7e7da1538c1ed0c65821e18233ec9dcdc6cd2b CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded (In reply to Telesto from comment #3) > @Regina > I have no idea what's going on here. The images in the example file have a > delayed execution or painting on screen when rotating. Apparently a thing > for years (at least also in 7.0.0.3) > > However there are cases where it simply works, like attachment 184430 [details] > [details] The difference between the two images in the test file is their color distribution. The right image has less colors and these colors are small peaks in the color histogram. The left image has about 1.5 times colors and wider peaks in the color histogram. When you reduce the colors of the left image to 16 colors (still with 24bit color depth), then the rotation is as immediate as with the right image. The conclusion for me is, to not burden images transformations to LibreOffice, but transform images in a dedicated image editing application and use the final result in LibreOffice.
(In reply to Regina Henschel from comment #4) > The conclusion for me is, to not burden images transformations to > LibreOffice, but transform images in a dedicated image editing application > and use the final result in LibreOffice. Seems quite a burden. I simply copy/pasted a couple image from the web. Wanted to rotate one of them for comparison, and encountered the quirky behaviour...
Also in Version: 6.1.6.3 Build ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL and in Versie: 6.0.4.1 Build ID: a63363f6506b8bdc5222481ce79ef33b2d13c741 CPU-threads: 4; Besturingssysteem: Windows 6.3; UI-render: GL; Locale: nl-NL (nl_NL); Calc: CL fine with Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: nl-NL (nl_NL); Calc: CL
75a5bb5fe97dc758e0a97b76c88f97b23c7dfd6b is the first bad commit commit 75a5bb5fe97dc758e0a97b76c88f97b23c7dfd6b Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat Nov 18 14:02:54 2017 +0100 source d74b26b41bfea3ba7a1834953b2bfe9b7ff0d70f source d74b26b41bfea3ba7a1834953b2bfe9b7ff0d70f source 1059e234f4b3b3f6b770b2e4d973923e54e7045b source 7d391f9a563041aae416c7017dcec36bbf4dfb2c source 4cee8018792c732aac638bd82c754ade915a4db9 source c82cb453eb56fb37ad36cff6becde9d753eb829d source da05b60cdb72d301c6b16c8cb31135f46f4ed2c0 source 51ee0c5ba6b0ffcd4b12e652de48e3f775cccc7d instdir/program/libbasctllo.so | Bin 2536288 -> 2536288 bytes instdir/program/librptlo.so | Bin 2297832 -> 2297832 bytes instdir/program/libsvxcorelo.so | Bin 12577640 -> 12577640 bytes instdir/program/libswlo.so | Bin 21830480 -> 21853064 bytes instdir/program/versionrc | 2 +- 5 files changed, 1 insertion(+), 1 deletion(-)