- 13 Nis, 2019 15 kayıt (commit)
-
-
Noel Grandin yazdı
Change-Id: I4ba0e1e982897bd570612f6cda8ba1e6a9fa5dbd Reviewed-on: https://gerrit.libreoffice.org/70700 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: I95c6fb5e2ddc1c2d8a2fb1d5ff30b18ddad48b3a Reviewed-on: https://gerrit.libreoffice.org/70699 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: I3f3108daf208fa8c6be90b28da5503846c27732e Reviewed-on: https://gerrit.libreoffice.org/70698 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Tomaž Vajngerl yazdı
Functions that scaled down had "2" at the end of the name so we could distinguish them from the scale up functions. This was hard to tell them apart, so rename the functions to reflect what they do. Change-Id: I9d88b86312e80b111439f1022212de07e53485d5 Reviewed-on: https://gerrit.libreoffice.org/70696Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
-
Tomaž Vajngerl yazdı
Until now we had RGB and BGR version. Because we never change the byte order when scaling and the scanline type, we can generalize the two funcions into one, where we only need to be careful that we don't change the order of color components. The same is done already for 4 variants of 32-bit bitmap, where we really only need 1 function for all 4 variants, using the same principle. Change-Id: I0f6d6b0c06a45e53bcd048e2ae009a471bf90a06 Reviewed-on: https://gerrit.libreoffice.org/70695 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
-
Tomaž Vajngerl yazdı
Most calculations work with integers for speed, which sacrifices some bits of an integer type for decimal values (fixed-point precision). In this case we used 7 bits for decimal values. This change makes the precision easily adjustable. In addition the actual type of bilinar weights, which was until now the type long (that hasn't a standardized bit length), but is now changed to sal_Int32 (so we know exactly how much bits we can use) and can be changed to sal_Int64 in the future if necessary by just adjusting the typedef. Change-Id: I8d41751c20e14cd1b9b64b055ff66bd1ca7c9f1d Reviewed-on: https://gerrit.libreoffice.org/70694 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
-
Jean-Pierre Ledure yazdı
Labels were present for each language in L10N module but applied nowhere.
-
Miklos Vajna yazdı
OpenGL just sets GtkSalGraphics::bNeedPixmapPaint to true, and the problem is specific to that flag (can be also enabled via SAL_GTK_USE_PIXMAPPAINT=1). Most other widgets are painted correctly in the GL case as they pass around a drawable explicitly; do the same for ControlType::ListNode as well in the GL case. The non-GL case still needs to go via the pixmap render macros to have correct position, leave that unchanged. Change-Id: Ia82a6772e357b434d706e58664be3a8427e91669 Reviewed-on: https://gerrit.libreoffice.org/70669 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
-
Noel Grandin yazdı
Change-Id: I7d85cbc9105c5e0c4a8d9a69c4ac9d6dfc07eabd Reviewed-on: https://gerrit.libreoffice.org/70663 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Andrea Gelmini yazdı
Change-Id: Iaa14545a19956b675ba8bbe0baf5d4ca8d86f518 Reviewed-on: https://gerrit.libreoffice.org/70692Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
-
Jan Holesovsky yazdı
Not to break the 'old' Android app, introduce a bool that can indicate if we are using the LOK from the 'old' (LOK-via-JNI-based) or from the 'new' (loolwsd-based) app. Change-Id: I38bd665cc1d5bc88018574171443ecabc46763df Reviewed-on: https://gerrit.libreoffice.org/70678Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com>
-
Noel Grandin yazdı
Change-Id: I9776431ebce95a88ae42715aaba2ddc28fb52471 Reviewed-on: https://gerrit.libreoffice.org/70642Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Andrea Gelmini yazdı
Change-Id: I2a73e84c9292dabeb5129b4261bb08c959b6b3e4 Reviewed-on: https://gerrit.libreoffice.org/70691 Tested-by: Jenkins Reviewed-by: Jens Carl <j.carl43@gmx.de>
-
Tomaž Vajngerl yazdı
We still miss the support in other function however. Change-Id: Ie87b588a9f8826242f4cff9d6671c98f3407f0e3 Reviewed-on: https://gerrit.libreoffice.org/70679 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
-
Tomaž Vajngerl yazdı
The old approach was to calculate the number of stripes of the bitmap per thread and later create the exact number tasks (ScaleTask) as there are threads, where each task would process stripes it had been given. This is needlesly complicated as the job of a thread pool is to properly delegate the tasks between threads. This was now changed so that we create one stripe per ScaleTask and let the threadpool delegate the tasks to its threads (that are available). It also wanted to be clever and use the main thread to do the work also, but it had a major flaw. The threadpool started to process the tasks only when "waitUntilDone" method was called, but the code first processed its slices and then called the threadpool method to start processing. Because of this the performance of scaling wasn't as good as it could be. This behaviour was now changed so that the main thread isn't involved in processing. It just creates the task, runs the threadpool and waits until the tasks are finished. Change-Id: I1e8c733bdbced8867d0a7f1190f0421a0cc3e067 Reviewed-on: https://gerrit.libreoffice.org/70668Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Tested-by: Tomaž Vajngerl <quikee@gmail.com>
-
- 12 Nis, 2019 25 kayıt (commit)
-
-
Caolán McNamara yazdı
Change-Id: If03c6ff8043bb39f2efdf4cde19d8277886bf36f Reviewed-on: https://gerrit.libreoffice.org/70658 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
probably missed loads more Change-Id: I53c9fe188055ef925fed54500e64b837cd56a1e7 Reviewed-on: https://gerrit.libreoffice.org/70676 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Noel Grandin yazdı
Change-Id: I211114140afc3f5b32b8b034e63e8d52f78be36a Reviewed-on: https://gerrit.libreoffice.org/70659 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Noel Grandin yazdı
Change-Id: I321c8eefdc43979ef5fd3774c7094ac0dbcac417 Reviewed-on: https://gerrit.libreoffice.org/70657 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Caolán McNamara yazdı
and so triggering a crash and exit on trying to get address of 0th element of a 0 len vector Change-Id: I205478b6c2878d3758d91812db46fe8ad58e37df Reviewed-on: https://gerrit.libreoffice.org/70672 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Mike Kaganski yazdı
Two tests in sc/qa/unit/pivottable_filters_test.cxx were extended to also test round-trip of group fields in XLSX. Change-Id: I70b7c15b09040c64fa1da2f88001af7ba16f2c6f Reviewed-on: https://gerrit.libreoffice.org/69653 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
-
Noel Grandin yazdı
Change-Id: I066b74763e45c785a9ebd7094fc33f44b8ddefb6
-
Caolán McNamara yazdı
Change-Id: Ie9dec478c38c484d47720e488427d797269f228f Reviewed-on: https://gerrit.libreoffice.org/70664 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
Change-Id: If42b676c3321d73455771b6ea62aefb806caccd2 Reviewed-on: https://gerrit.libreoffice.org/70661 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Stephan Bergmann yazdı
Can't remember a good reason not to. Change-Id: Ie2c62783465b917696d19e66159b5862512c7a54 Reviewed-on: https://gerrit.libreoffice.org/70655 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
-
Noel Grandin yazdı
Change-Id: I1a08f3684b785e31535adcfb4220ded267a77c3b Reviewed-on: https://gerrit.libreoffice.org/70643 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Henry Castro yazdı
Change-Id: I91fbfd97da0c4ad1ad90710ab781c71ca99367e5 Reviewed-on: https://gerrit.libreoffice.org/70609 Tested-by: Jenkins Reviewed-by: Henry Castro <hcastro@collabora.com>
-
Noel Grandin yazdı
Change-Id: Ic3c854c831b5b9507e2f1a691adf6a2269b3875b
-
Caolán McNamara yazdı
Change-Id: I35fa2f63eb47f18289892ffcf042d041752bfbd7 Reviewed-on: https://gerrit.libreoffice.org/70653 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
Change-Id: I976fb892f8ac1dedb0c2c3110dce17c1211de238 Reviewed-on: https://gerrit.libreoffice.org/70652Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Noel Grandin yazdı
Change-Id: Ie90e53583484ee4f378ec92634adf3be7cd9ecbb Reviewed-on: https://gerrit.libreoffice.org/70650 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Tor Lillqvist yazdı
I wonder wheter we should just include all of instdir/share. Seems that I have to add more and more of it all the time anyway. I don't remember why I thought (many years ago) that an app would need just a subset. (Maybe I thought that an app would not, at least not initially, have functionality that would use most of the stuff in shre. But that has changed now.) Change-Id: I62f935e3ab9c4709373fad11ed120ecca033b4aa
-
Gabor Kelemen yazdı
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ia418fdf7077d1c0c169671770237381c4da7b7b0 Reviewed-on: https://gerrit.libreoffice.org/70582 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
-
Tomaž Vajngerl yazdı
When we want a different size Image, we can now set that as a parameter at construction of the Image. Previously we needed to create an Image, forcefully take the bitmap out, resize the bitmap and create a new Image out of that. Doing it internally gives us the benefit to have a more control over the scaling process, especially when dealing with HiDPI images. Change-Id: I104118f4d863d519cc7aad1a17ca0289c01ed9ff Reviewed-on: https://gerrit.libreoffice.org/70617 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
-
Tor Lillqvist yazdı
Quikee said it was OK. Change-Id: I8f45d3c5e264f5658985399487e9c6e2a3fbced3
-
Noel Grandin yazdı
Change-Id: I984717138ac85c1af5fc363fda06f5c2b5497965 Reviewed-on: https://gerrit.libreoffice.org/70641 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
-
Caolán McNamara yazdı
since... commit 7282014e Date: Fri Feb 1 15:15:16 2019 +0100 tdf#50916 Makes numbers of columns dynamic Change-Id: I7a624f391c85f9c7af07f951c9da3914460b7526 Reviewed-on: https://gerrit.libreoffice.org/70602 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
Change-Id: I1e1d31551b623453a1bade9c932ef1c9e1060f35 Reviewed-on: https://gerrit.libreoffice.org/70600 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Caolán McNamara yazdı
since... commit 7282014e Date: Fri Feb 1 15:15:16 2019 +0100 tdf#50916 Makes numbers of columns dynamic Change-Id: Ib42b770282753350b9c4016fe7c9f57f68e6c209 Reviewed-on: https://gerrit.libreoffice.org/70603 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
-
Miklos Vajna yazdı
The hack added in commit 3325e0f2 (bnc#865381 DOCX import: handle w:jc=center inside w:textDirection=btLr, 2014-07-02) is no longer needed, actually just reverting it fixes the problem, as then layout does the right thing. No need to center paragraph adjustment to any kind of vertical orientation, now that we have proper layout support. Change-Id: I6aa74f5289a014c148fbd7c7ab03ec885d931daf Reviewed-on: https://gerrit.libreoffice.org/70610 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
-