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>
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>
Graphic::makeAvailable() is not thread-safe, but the jpeg loader
is capable of that, and the graphic can be loaded using the stream
data (which is what ultimately makeAvailable() will do anyway).
This loads all images faster using threads instead of them being
loaded one by one on-demand.
Change-Id: Ifc39a2757834a9fb0dbafa61f13f5454e69af330
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104082
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
introducing mbAlreadyStepped flag to make physics animation effects
aware that the lock was just obtained from another physics animation
which already stepped the time interval meant to be stepped through.
Change-Id: Id7c01c96e302d7da7aae785f56c09a9ddfe4bdf1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101665
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
fixes the bug where an animation effect doesn't start on it's original location
and collides with everything as if it was moving from the original location to
wherever the animation effect starts in a single step.
Change-Id: Icd2919bcad665f8a1839a57642694d98ff73afca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101425
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office
internal macro for now", so take the liberty of removing it, even if technically
that can be considered an incompatible API change.
Change-Id: I7580a932e1da54845934378a650e894f3f3a9062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Making box2d world only stay populated when there's an animation
effect going on. This makes it possible to get rid of big chunk
of sequential update implementation.
Change-Id: Iaf50d4871b2355035495618354f0ae09abe94164
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101304
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Mike Kaganski