Armin Le Grand (collabora)
52ec9f11d8
We already did some improvements, but I wanted to clean this up somewhat. Reason for the needed corrections was in principle the sqrt()-based general calculation of the HoldTime in the default implementation of calculateCombinedHoldCyclesInSeconds. The original idea was to hold huge data shorter due to memory constraints. To solve that we added an adapted version to CairoPixelProcessor2D. With lessons learned I decided to remove that and provide a revised general implementation based on linear scaling of the HoldTime. Based on assuming the seen huge Bitmap and estimating 20min for it, just create a factor and multiply with SizeInBytes. I checked that and it works as intended. It will spare us from this problem re-occurring with future SDPRs. NOTE: This still keeps the CairoSDPR-specific avoiding of buffering of small Bitmaps when these are available from Bitmap directly. This stays useful and is Cairo-specific. Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com> Change-Id: I30c7361c6fbfaf0be90be353091cbaf831db5cd2 Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2005 Tested-by: Jenkins CPCI <releng@collaboraoffice.com> Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com> (cherry picked from commit a3d3ae5e931a04ff5718382ccffe9f16de336a42) (cherry picked from commit 7550c6ea0bb82f7574e4b974f8d24bd1662a878b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205991 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
Algorithms and Data Types for Graphics
Algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in canvas).