1. 09 Ock, 2019 1 kayıt (commit)
  2. 08 Ock, 2019 1 kayıt (commit)
  3. 31 Ara, 2018 1 kayıt (commit)
  4. 08 Ara, 2018 1 kayıt (commit)
  5. 05 Ara, 2018 1 kayıt (commit)
  6. 25 Kas, 2018 1 kayıt (commit)
  7. 24 Kas, 2018 2 kayıt (commit)
  8. 22 Kas, 2018 1 kayıt (commit)
  9. 16 Kas, 2018 1 kayıt (commit)
  10. 06 Kas, 2018 1 kayıt (commit)
  11. 03 Kas, 2018 1 kayıt (commit)
  12. 24 Eki, 2018 1 kayıt (commit)
  13. 23 Eki, 2018 1 kayıt (commit)
  14. 22 Eki, 2018 1 kayıt (commit)
  15. 20 Eki, 2018 1 kayıt (commit)
  16. 19 Eki, 2018 1 kayıt (commit)
  17. 15 Eki, 2018 1 kayıt (commit)
  18. 09 Eki, 2018 1 kayıt (commit)
  19. 07 Eki, 2018 1 kayıt (commit)
  20. 06 Eki, 2018 1 kayıt (commit)
  21. 21 Eyl, 2018 1 kayıt (commit)
    • Armin Le Grand's avatar
      Support buffering SystemDependent GraphicData · 80b287ad
      Armin Le Grand yazdı
      Started to make the buffering more flexible by adding
      virtual methods
      
              virtual sal_uInt32 getHoldCyclesInSeconds() const;
              virtual sal_Int64 estimateUsageInBytes() const;
      
      to class SystemDependentData. This will allow to add more
      sensitive buffering/caching.
      Also fine-tuned Linux-derived classes actively used for buffering
      to be more sensitive when and where to reuse the buffered data
      
      Change-Id: Ifc69c318ade0209aff071d76001869d9f4eeb10d
      Reviewed-on: https://gerrit.libreoffice.org/60881
      Tested-by: Jenkins
      Reviewed-by: 's avatarArmin Le Grand <Armin.Le.Grand@cib.de>
      80b287ad
  22. 20 Eyl, 2018 1 kayıt (commit)
    • Armin Le Grand's avatar
      Support buffering SystemDependent GraphicData (III) · 66232248
      Armin Le Grand yazdı
      This change is for speedup of fat line drawing when using
      X11. This is a long-term problem which never really progressed,
      but is avoided using Cairo in the future. Still - if used,
      speedup using current state and buffering possibilities.
      
      Two speedup steps will be used:
      (1) The tesselation is no longer done using trapezoids. That
      works (but was done wrong leaving artifacts) but is not fast
      and done every time. It is even not done with FatLines and
      more than 1000 points.
      New version will use triangulation. Dspite using the existing
      triangulator (that works but is slow) extend the FatLine
      geometry creator to directly create triangles.
      This is also necessary since for buffering that data a
      transformation-invariant version is needed (in device coordinates
      the data changes all the time when scrolling). Trapezoids are
      by definition *not* transformation-invariant (e.g. rotation)
      
      (2) Buffer that triangulation - with the needed care and watch.
      It is e.g. necessary to react on 'hairlines' since these change
      their logical LineWidth view-dependent (zoom). In those cases, the
      buffered data *has* to be removed due to the base for buffering is
      the created FatLine geometry based on one stable logical LineWidth
      
      Also took the time to adapt B2DPolygonTriangulator to use an
      own data type (B2DTriangle) and a vector of these for better
      understandability and security. Adapted all usages as needed.
      
      Change-Id: Iedb2932b094a8786fd9c32d0d0ab1ca603a1a7b2
      Reviewed-on: https://gerrit.libreoffice.org/60818
      Tested-by: Jenkins
      Reviewed-by: 's avatarArmin Le Grand <Armin.Le.Grand@cib.de>
      66232248
  23. 17 Eyl, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      New loplugin:external · 206b5b26
      Stephan Bergmann yazdı
      ...warning about (for now only) functions and variables with external linkage
      that likely don't need it.
      
      The problems with moving entities into unnamed namespacs and breaking ADL
      (as alluded to in comments in compilerplugins/clang/external.cxx) are
      illustrated by the fact that while
      
        struct S1 { int f() { return 0; } };
        int f(S1 s) { return s.f(); }
        namespace N {
          struct S2: S1 { int f() { return 1; } };
          int f(S2 s) { return s.f(); }
        }
        int main() { return f(N::S2()); }
      
      returns 1, both moving just the struct S2 into an nunnamed namespace,
      
        struct S1 { int f() { return 0; } };
        int f(S1 s) { return s.f(); }
        namespace N {
          namespace { struct S2: S1 { int f() { return 1; } }; }
          int f(S2 s) { return s.f(); }
        }
        int main() { return f(N::S2()); }
      
      as well as moving just the function f overload into an unnamed namespace,
      
        struct S1 { int f() { return 0; } };
        int f(S1 s) { return s.f(); }
        namespace N {
          struct S2: S1 { int f() { return 1; } };
          namespace { int f(S2 s) { return s.f(); } }
        }
        int main() { return f(N::S2()); }
      
      would each change the program to return 0 instead.
      
      Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
      Reviewed-on: https://gerrit.libreoffice.org/60539
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      206b5b26
  24. 13 Eyl, 2018 1 kayıt (commit)
    • Armin Le Grand's avatar
      Support buffering SystemDependent GraphicData (II) · 7034311d
      Armin Le Grand yazdı
      In this step I have changed all calls that use a
      B2DPolyPolygon and do filled graphics, added support for
      providing needed transformation which will -if supported-
      be used. Added buffering of SystemDependentData at
      B2DPolyPolygon for that purpose, see comments describing
      the current possibilities in the Gdiplus implementation.
      
      Moved lifetime creation/cleanup of SystemDependentDataManager
      to ImplSVData due to cleanup problems in the clang build
      
      Tried to use a std::unique_ptr to hold the instance
      of a SystemDependentDataBuffer at ImplSVData and cleanup
      inside DeInitVCL() right before ::ImplDeInitScheduler. This
      works in principle, but scheduler shutdown triggers
      ProcessEventsToIdle which leads to repaints and re-creates
      the buffer. Will now do exactly as was done with GdiPlusBuffer
      before, a simple local static incarnation and a call to
      SetStatic() in constructor
      
      Splitted SystemDependentDataBuffer and Timer due to
      different LifeTimes. Timer needs to be destructed
      earlier than SystemDependentDataBuffer, before
      Scheduler::ImplDeInitScheduler() is called from
      DeInitVCL()
      
      Change-Id: I2134e4346a183a4cee1be3428c51541cc8867c11
      Reviewed-on: https://gerrit.libreoffice.org/60102
      Tested-by: Jenkins
      Reviewed-by: 's avatarArmin Le Grand <Armin.Le.Grand@cib.de>
      7034311d
  25. 11 Eyl, 2018 1 kayıt (commit)
  26. 09 Eyl, 2018 1 kayıt (commit)
  27. 05 Eyl, 2018 1 kayıt (commit)
  28. 03 Eyl, 2018 1 kayıt (commit)
  29. 01 Eyl, 2018 1 kayıt (commit)
  30. 31 Agu, 2018 1 kayıt (commit)
  31. 30 Agu, 2018 1 kayıt (commit)
    • Armin Le Grand's avatar
      Support buffering SystemDependent GraphicData · b9fa01a8
      Armin Le Grand yazdı
      This is a first step to allow buffering of system
      dependent data, especially (but not only) for the
      system-dependent implementations of graphic output.
      For example, for B2DPolygon and Win output, it allows
      buffering the Gdiplus::GraphicsPath instead of re-
      creating it all the time.
      To support that, the change includes forwarding the
      current transformation to the renderers in SalGraphics.
      The current state in VCL is to transform all and
      everything to device coordinates at every single
      paint.
      I have currently started to do this for ::drawPolyLine
      implementations. The fallbacks for all systems will
      at the start of that method just transform the data
      to device coordinates, so all works as before.
      This may also be done for FilledPolygon paint in a later
      step, but most urgent is FatLine painting.
      An arrangement of shared_ptr/weak_ptr is used so that
      either the instance buffering (in the example B2DPolygon)
      or the instance managing it can delete it. The instance
      managing it currently uses a 1s Timer and a cycle-lifetime
      management, but that can be extended in the future
      to e.g. include size hints, too.
      The mechanism it designed to support multiple Data per
      buffering element, e.g. for B2DPolygon at the same time
      system-dependent instances of Gdiplus and Cairo can be
      buffered, but also PDF-data.
      This is achieved semi-automatic by using
      typeid(class).hash_code() as key for organization.
      The mechanism will be used for now at B2DPolygon, but
      is not limited to. There is already a similar but less
      general buffer (see GdiPlusBuffer) that can and will
      be converted to use this new mechanism.
      
      Added vcl/headless Cairo renderer to support given
      ObjectToDevice transformation (not to transform given
      B2DPolygon)
      Added support for CairoPath buffered at B2DPolygon,
      seems to work well. Need to do more tests
      
      Moved usage to templates suggested by Noel Grandin
      (Noel Grandin <noelgrandin@gmail.com>), thanks for
      these suggestions. Adapted Win usage to that, too.
      
      Converted Win-specific GdiPlus BitmapBuffer to new
      mechanism, works well. Checked, the manager holds
      now a mix of bitmap and path data under Win
      
      Added a cleanup mechanism to flush all buffered data
      at DeInitVCL() using flushAll() at
      SystemDependentDataBuffer
      
      Adapted Linux-versions of ::drawPolyLine to support
      PixelSnapHairline, for now in a simplified version
      that still allows buffering. This will also be used
      (and use buffering) for the Cairo-fallback in
      X11SalGraphics
      
      Change-Id: I88d7e438a20b96ddab7707050893bdd590c098c7
      Reviewed-on: https://gerrit.libreoffice.org/59555Tested-by: 's avatarArmin Le Grand <Armin.Le.Grand@cib.de>
      Reviewed-by: 's avatarArmin Le Grand <Armin.Le.Grand@cib.de>
      b9fa01a8
  32. 17 Agu, 2018 1 kayıt (commit)
  33. 14 Agu, 2018 3 kayıt (commit)
  34. 11 Agu, 2018 1 kayıt (commit)
  35. 04 Agu, 2018 1 kayıt (commit)
  36. 03 Agu, 2018 1 kayıt (commit)
  37. 20 Tem, 2018 1 kayıt (commit)