The PCH brings in <numeric>, which has std::accumulate(), which also
gets considered for whatever reason.
Change-Id: I69f375c871034e156598c8886822279f78c7f73f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119010
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
since...
commit 9090dc1f3b
Date: Mon Jan 18 18:27:19 2021 +0200
split OutputDevice from Window
note SpriteDeviceHelper::getDeviceHandle seems to return a vcl::Window
and not an OutputDevice like the other ::getDeviceHandle so that
probably needs changing too, or the others need to return the owner
window.
Change-Id: I84da379e680d3da5775855a16dc716decef22bbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116052
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Jenkins
Rather use a proper alpha channel if we need transparency.
This is another small step towards merged alpha in our vcl
layer.
I suspect the intent in a lot of this code was to save memory.
Which have been a thing way back then, but these days our
backends mostly end up doing a copy-and-convert to a real
alpha channel anyway, so the existing code is actually
now a pessimisation.
Change-Id: I4a2bcbb2f76b841f05bc00580f364492829c69de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114808
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
So that we have fewer cases to deal with when we transition to
32-bit bitmaps.
(*) rename maMask to maAlphaMask, since now it is only being used
for alpha duties.
(*) drop mbAlpha and mbTransparent to simplify state management,
the only thing we need to check for alpha is if maAlphaMask is
non-empty.
Change-Id: I06252e38e950e846a94b4c2ba8ea763be17801fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111679
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
These animations were causing problems because of Cairo not handling
well large matrix values. With the real problem fixed this can now
be reverted. I assume the commit claiming to occur with OpenGL was
a mistake, I cannot reproduce any problem, or possibly the problem
went away when the OpenGL VCL backend was removed.
This reverts commit 8eb2d29725.
This reverts commit 3e88fc6b0e.
Change-Id: I1c1fff94ff65c7937197a32176a8775ecb2a502e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114345
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Renaming all README files for all top level modules to README.md,
applying no content change at this stage to be able to track history
of the files. These files should be edited to use correct Markdown
syntax later.
Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
With that compiler version (and --with-latest-c++), the build now started to
fail for me with
> [build CXX] slideshow/source/engine/opengl/Operation.cxx
> C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1428~1.299\Include\memory(14): error C2220: the following warning is treated as an error
> C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1428~1.299\Include\memory(14): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
> C:\lo\core\slideshow\source\engine\opengl\Operation.hxx(34): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
> C:/lo/core/slideshow/source/engine/opengl/Operation.cxx(36): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop)
Mike had experienced the same (though without --with-latest-c++, but due to us
now always using /permissive-) as explained in the post-merge comments starting
at <https://gerrit.libreoffice.org/c/core/+/108961/4#
message-cc2a1e2ebaeb96cbacd7d13d57ffc701f2ed4608> "Use MSVC's /permissive- to
make it more standards conforming", linking to
<https://developercommunity.visualstudio.com/t/
warning-c4103-in-visual-studio-166-update/1057589> "Warning C4103 in Visual
Studio 16.6 Update".
At least for my --with-latest-c++ aka /std:c++latest case, I have reduced the
issue to a test.cc of
> #include <cmath>
> template<typename> void f(int[1]) {}
> #include <exception>
failing with
> **********************************************************************
> ** Visual Studio 2019 Developer Command Prompt v16.9.0
> ** Copyright (c) 2021 Microsoft Corporation
> **********************************************************************
> [vcvarsall.bat] Environment initialized for: 'x64'
>
> C:\Program Files (x86)\Microsoft Visual Studio\2019\Community>cd \lo\core
>
> C:\test>cl /std:c++latest /c test.cc
> Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29910 for x64
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> /std:c++latest is provided as a preview of language features from the latest C++
>
> working draft, and we're eager to hear about bugs and suggestions for improvemen
> ts.
> However, note that these features are provided as-is without support, and subjec
> t
> to changes or removal as the working draft evolves. See
> https://go.microsoft.com/fwlink/?linkid=2045807 for details.
>
> test.cc
> test.cc(3): warning C4103: alignment changed after including header, may be due
> to missing #pragma pack(pop)
which looks clearly like a compiler bug.
As it happens, reordering the includes here makes the issue disappear at least
for me.
Change-Id: Ib3d0756b38da4f24e62cafa900b44c8ec8e842b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112317
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
because of the side effects
using a bare GtkGrid as m_pSocket in vcl/unx/gtk3/gtk3gtkobject.cxx
is perhaps a poor choice, getting its xid causes poor side effects
wrt events belonging to its child widgets getting delivered to
the SalFrame widget, so duplicate scrolling after showing a opengl
slide and/or showing a video and lots of flickering
we're (generally at least) not using the xid under gtk3 so don't set it
unless it's explicitly asked for. Happily the gtk Player::createPlayerWindow
doesn't use its arg[0] xid in any case, so don't bother setting it for
that backend.
Change-Id: I1c59a607a332635091782c3b49de10647558f301
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109941
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
To fix tdf#131254, forceEmpty call removed without a control.
Bug was related advance time setting. Now we control if slide has
advance time setting.
Change-Id: Ie83f4d7ff3e4bd0a744ca205173d747204918b39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108282
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
The VCL OpenGL backend code has been removed, so the settings
for it no longer make sense.
But there's still the code for detecting if OpenGL is broken,
and that one makes sense to keep. It turns out other OpenGL code
(such as slideshows) doesn't even use that, so turn this into
a new DisableOpenGL option, make OpenGL-related failsafe code
set and use that, and OpenGL code should use
OpenGLHelper::supportsOpenGL() to make sure OpenGL use is not blocked.
Change-Id: Iec83f204e89bfb0b6eea13be77da8f0f4727a074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107398
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Mike Kaganski