Description: To reproduce: - new draw/impress - insert any shape (needs not to be big, I used small PNG) - select, use pos/size dialog (context menu) - set size to (0, 0) -> often SlideSorter left already shows problems -> does not crash immediately, but *somehow* creates mem errors Steps to Reproduce: See description above. Actual Results: See description above. Expected Results: See description above. Reproducible: Always User Profile Reset: No Additional Info: See description above.
Created attachment 202208 [details] Testfile with which this happens when CairoSDPR is in use
Debugged into it - I thought it might be MipMapping I am doing in buffred cairo surfaces of that bitmap (CairoSDPR uses discrete target width/height to better prepare for paint), but this is not the problem. Indeed cairo gets a transformation set with an XScale/XScale of 0.05 which leads to a discrete width/height of 0/0 to paint, but the error and mem mayhem indeed happens *inside* cairo in the call to cairo_paint- the values are correct. This is potentially dangerous, theoretically every paint would need to be checked for zero size discrete output... Looking for possibly better solution... I use a created testdoc with a smaller image. If I try to check where the error really occurs with that one it does not happen immediately, but e.g. the display on the slide in the left pane gets already wrong. Thus I guessed it maybe the slide visualization. I checked again with the orig doc & hiding that panel (so previews get not created), but same error. I will now try to just secure all pixel data outputs in CairoSDPR if they get to discrete zero dimension in X *or* y, that should solve it. Solution on gerrit, see https://gerrit.libreoffice.org/c/core/+/189135
Armin Le Grand (collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cd93f83bbcba0379bf39f3a4e76b955b7fa368b5 tdf#167831 avoid painting bitmap data with zero dimensions It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Looked at performance, indeed BitmapReadAccess is the problem. Thoght about directly creating needed MipMap size, but that would *also* need read access over all data since pixels need to be mixed -> same read accesses, so no improvement. sigh...