| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reminds me - again - that Jenkins doesn't run make check.
It turns out InSendMessage() also returns true, if you process a
nested SendMessage in the same thread. Therefore we have to
remove the SalComWndProc assert and just keep the one in the
Yield call.
Why? Because there seem to be no way to get the information
ReplyMessage has access to, so we could detect the caller /
origin of the send message and implement proper nested call
checks. The alternative would be to change all call sites of
SendMessage to:
if ( !pSalData->mpInstance->IsMainThread() )
SendMessage(...)
else
SalComWndProc(...)
which is the same SendMessage already does.
Change-Id: I991d68a64952dc5d47ba51edd8635c9e8c46614c
Reviewed-on: https://gerrit.libreoffice.org/59538
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit bf0a63dc93a746a008fb1656457c77de8df693ba)
Reviewed-on: https://gerrit.libreoffice.org/59565
(cherry picked from commit a42c65176f2791cf5e48578a8898bf03185adc89)
Reviewed-on: https://gerrit.libreoffice.org/60726
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
This bug trips "assert( !pInst->mbNoYieldLock )".
There is already a special case, introduced in commit 4baec725e0dc
("WIN run main thread redirects ignoring SolarMutex"), to prevent
tripping the assert for a nested SendMessage call.
So this implements a general solution for nested SendMessage calls.
We just have to prevent yielding in a call from an other thread,
as the sending thread still owns the SolarMutex.
This way we can also drop the special handling in
WinSalFrame::ReleaseFrameGraphicsDC.
Conflicts:
vcl/win/app/salinst.cxx
Change-Id: I7024b081b26f3545af12a3a3a038fe5e5671af3c
Reviewed-on: https://gerrit.libreoffice.org/59275
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 35a254750392dcd738481f5d6e8719cee9fb41b3)
Reviewed-on: https://gerrit.libreoffice.org/59318
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(cherry picked from commit 3e392904c558d1f9fc91926511d148762813537e)
Reviewed-on: https://gerrit.libreoffice.org/60725
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
On Windows 10, Explorer spends ridiculous amounts of CPU with updating
its recent documents view while tests are running.
(cherry picked from commit 94c264859f621e8e7c793fad2beb6528659433bf)
It's much better to check IsHeadlessMode anyway because that is set in
more situations, and if you run soffice --headless you probably don't
want the corresponding files to show up in Explorer's Recently list.
(cherry picked from commit b07e8a7e16ba69e822a309ec280d1987f90021a3)
Change-Id: I8ada3659d05c94d072ba30859090e835a595e9ea
Reviewed-on: https://gerrit.libreoffice.org/53115
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
For DC initialization we check the thread ID to assign a normal
or cached DC to the corresponding WinSalGraphics variable.
The cached DC has a usage count, as there are some limits on
cached DCs count (DCX_CACHE).
But for the WinSalGraphics DC init and release the variable just
matters for the accounting, and generally which thread is doing
the calls: the non-main thread always has to relay them to the
main application thread.
Since we're releasing all WinSalGraphics in ~WinSalFrame and do
all release and re-init in ImplSetParentFrame, there is no way
to correspond the thread ID to the WinSalGraphics variable.
So this drops the wrong assertions based on the WinSalGraphics
variables and renames the GETDC message to GETCACHEDDC to make
usage of a cached DC (DCX_CACHE) more obvious.
As a consequence of the different release DC handling this also
fixes the accounting of the cached DCs, wich was broken in the
initial fix; commit c15ea73f960bbd3d2a4b0c43b467ac62eeba3505
Change-Id: I11ce52a1b4005f26567f92588437fa37bf227a2e
Reviewed-on: https://gerrit.libreoffice.org/51318
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
(cherry picked from commit 8939cb9456ee76a848cc8089747f280751092cf8)
Reviewed-on: https://gerrit.libreoffice.org/51549
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
so drop param and rename to ReleaseYieldMutexAll
Change-Id: Ic4fcee24d46405659e54363c87f21d88696b0ce1
Reviewed-on: https://gerrit.libreoffice.org/44057
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4a0fc4b483069141d2b943079adf5aa741df968e
|
|
Change-Id: I468d951007089fefc235e245c3cb4baea4aa51f7
|
|
Replace a lot of duplicated case code with macros.
Some minor constifications of function parameters.
I restrained from shorten the SAL_MSG_* via preprocessor concat,
so a grep will still find the whole names.
Change-Id: If1f2477fc8817b4ae7816e807154e35004bb4da9
Reviewed-on: https://gerrit.libreoffice.org/43531
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The code did acccount processing of an invaild timeout system
message as a valid timeout event.
Change-Id: I3c31f8b9cec592631b4089411163dadecffde816
Reviewed-on: https://gerrit.libreoffice.org/43529
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I8f689ba1a26b2380b1962a47837b943fbefbd6b6
Reviewed-on: https://gerrit.libreoffice.org/43383
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
During window move and resize, Windows spawns a nested message
loop, blocking our direct processing. In this case we switch to
timer messages for all timeouts.
But if LO is busy with background jobs, the posted 0ms timer
messages will block any system event processing, halting any
updates until we're idle again. So for these cases we switch
to the WM_TIMER based SetTimer timer.
Change-Id: I854f4984d7c75d6829f82cda5cb4479967edce48
Reviewed-on: https://gerrit.libreoffice.org/43350
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
On Windows we can just check the message queue for existing
messages. But VclInputFlags::OTHER is used to check for any
messages, which can't be explicitly checked.
In the case of checking for VclInputFlags::OTHER while
excluding an other message type, we have to make multiple
PeekMessage calls and exclude all non-checked message ids.
Change-Id: I1cedd4b76444769842c74228fc547f0d924f8b60
Reviewed-on: https://gerrit.libreoffice.org/43337
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This time we skip the intention to handle our Scheduler
completely via the system event loop. Instead we basically
guarantee to process a Scheduler event during each DoYield,
if one is available. This way we won't block system events
when busy in our event loop.
Change-Id: I37094e61cbf928733151d9cc3299cdac76b3a5cd
Reviewed-on: https://gerrit.libreoffice.org/43349
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b)
it was expected to gradually remove SAL_U/W usage in Windows code
by replacing with reinterpret_cast or changing to some bettertypes.
But as it's useful to make use of fact that LibreOffice and Windows
use compatible representation of strings, this commit puts these
functions to a better-suited o3tl, and recommends that the functions
be consistently used throughout Windows-specific code to reflect the
compatibility and keep the casts safe.
Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6
Reviewed-on: https://gerrit.libreoffice.org/43150
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic173e38828b04fd177d62551e3323b816c73d556
Reviewed-on: https://gerrit.libreoffice.org/42980
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
We should only use generic foo function name when it takes params
that are also dependent on UNICODE define, like
LoadCursor( nullptr, IDC_ARROW )
where IDC_ARROW is defined in MSVC headers synchronised with
LoadCursor definition.
We should always use Unicode API for any file paths operations,
because otherwise we will get "?" for any character in path that
is not in current non-unicode codepage, which will result in failed
file operations.
Change-Id: I3a7f453ca0f893002d8a9764318919709fd8b633
Reviewed-on: https://gerrit.libreoffice.org/42935
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Since we dropped support of Vista and below in master toward 6.0,
those checks are needless. Removing the code that only worked in
older versions, and streamlining the resulting code.
Also, use kernel32.dll version for Windows version, instead of
deprecated GetVersionEx, and inconvenient VersionHelpers. Since both
GetVersion(Ex) and VersionHelpers (based on VerifyVersionInfo) are
subject to manifest-based behavior since Windows 8.1, this move will
hopefully result in more reliable OS version detection.
Change-Id: I3edd8fc1843e64b6a65bd3a126be6a085511f13c
Reviewed-on: https://gerrit.libreoffice.org/42905
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I230c37482cfce85534f860ecf3426254be8981ab
|
|
Change-Id: I472df5821cb74a16d5ea00a1939b0e1bdf9072aa
Reviewed-on: https://gerrit.libreoffice.org/42518
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This prevents blocking the main thread by a yielding non-main thread.
The current solution is to wait on a condition, which is set by the
main thread on wakeup.
Change-Id: I8d680bb51a36ce1e0d3d4713d47d8e2ef93d7297
Reviewed-on: https://gerrit.libreoffice.org/42808
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Application::Reschedule(true) must just process all currently
pending events and ignore all new events generated while processing
them. In contrast to Scheduler::ProcessEventsToIdle, this way it
can't busy-lock the application with background jobs.
This way we also can drop nMaxEvents from the Windows backend. This
limit was also never implemented on OSX and for the KDE4 backend
it's actually impossible to handle single events, and a call to
QAbstractEventDispatcher::processEvents works like this.
Also changes various call sites to just process all pending events
instead of some made up number of times.
Change-Id: I1ab95df89b079cc8c6319a808194fe3127144d1c
Reviewed-on: https://gerrit.libreoffice.org/42659
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This way we can drop all the special nReleased handling. Instead
we use the same mechanism as on Mac, where we keep the lock, but
disable it for the main thread. As a security measure we assert on
duplicate redirects, which should not happen.
As a result we can't use SendMessage on the main thread itself,
which would normally just call the WinProc directly. This could be
accomplished by converting the redirect bool into a counter, which
should be safe, as no other thread could acquire the SolarMutex,
as we don't release it.
Change-Id: Icd87b3da37a2489f3cad2bc80215bf93fc41d388
Reviewed-on: https://gerrit.libreoffice.org/42583
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I30d8998b5f9ff29b8a3e8012f6112de597933d10
|
|
Fixes the "Multiple timers in queue" assertion by effectively
removing it.
When debugging it became obvious, that PostMessage returns, even
if the message was not yet added to the message queue.
The assert happens, because we start the timer in the Scheduler
before Invoke(), so it fires, if we block in Invoke(), and then
reset the timer after Invoke, if there were changes to the Task
list.
In this case it fires during Invoke(), the message is added. We
restart the timer, first by stopping it (we wait in
DeleteTimerQueueTimer, to be sure the timer function has either
finished or was not run). And the try to remove the message with
PeekMessageW, which doesn't remove the posted message.
Then the timer is restarted, and when the event is processed, we
end up with an additional timer event, which was asserted.
As a fix this adds a (microsecond) timestamp to the timer message,
which is validated in the WinProc function. So if we stop the
timer too fast, the event is ignored based on the timestamp.
And while at it, the patch moves timer related variables from
SalData into WinSalTimer.
Change-Id: Ib840a421e8bd040d40f39473e1d44491e5b332bd
Reviewed-on: https://gerrit.libreoffice.org/42575
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
...introduced with 3840aede596e6fc24f7ed7df9100fb028134aac6 "Unify SolarMutex
implementations" (causing link failure and clang-cl loplugin:unreffun with
64 bit Windows builds)
Change-Id: I273d15e74ad88648ebbccb33f1348497779cc488
|
|
All backends implement the SolarMutex in mostly the same way.
So this consolidates this code into a GenericSolarMutex.
We still need the abstract SolarMutex class for the fake AKA
fascade implementation in dbaccess.
The patch also replaces various places of direct mutex usage with
either SolarMutexGuard or SolarMutexReleaser objects.
Change-Id: Ia0146dd6c51a3b9a513cc6af34a66def58aad831
Reviewed-on: https://gerrit.libreoffice.org/42325
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
I hit it multiple times and have no interest in figuring out
why. Or time.
Change-Id: I3f22c8b62fdcf987b760ac16bfe8a21a8870d33e
Reviewed-on: https://gerrit.libreoffice.org/42212
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
Most of these were converted from OSL_ASSERT
Change-Id: Ia95a758cdebf72ee80d00866644d92e6bb915071
|
|
I doesn't seem possible to post an event deterministically to the
end of the Windows message queue and then process this queued
events "in order".
PeekMessage and now even DispatchMessage process events out of
order - that's how this assert was hit. I was quite sure it would
not hit, but a simple resize proved me wrong. And the assert just
proved that all my assumptions were wrong :-(
So this gives up the whole idea of a short-circuit message queue
handling on Windows for busy processing of LO Idles and goes back
to some kind of the original "always timer" implementation. Since
the "parallel" processing of LO events after system messages
during DoYield was dropped, this might be slower; or not.
In the end this simplifies the main loop almost to the starting
point, except for a little busy loop, if we wait for an Idle event
timer - not so busy acually, as we just switch to another local
thread, which hopefully is our idle timer waiting to fire.
A short-circuit with a little detour.
Change-Id: Id63a2a9e2a3b1501ad50a2c6f308a36efe55e68f
|
|
Actually we just want to remove the SAL_MSG_TIMER_CALLBACK
messages, but this seems to be impossible using PeekMessage,
without the side effect of processing some messages:
"During this call, the system delivers pending, nonqueued
messages... Then the first queued message that matches the
specified filter is retrieved.".
But it is actually enought to ignore the SAL_MSG_THREADYIELD
message send using SendMessage from DoYield, which can be
filtered by using PM_QS_POSTMESSAGE.
Probably this should be resolved not using PeekMessage at all
by using a variable to hold the time of the last posted
SAL_MSG_TIMER_CALLBACK message, so we just run the callback
once, if our time is <= MSG time and ignore the multiple
queued messages. Same for mbOnIdleRunScheduler handling.
Change-Id: Ifacb20aa38e6b5aca908e5411cf2e100f702ad1f
|
|
The scheduler is restarting the timer at the end of the most
important task search. It uses PeekMessage PM_REMOVE to remove
old SAL_MSG_TIMER_CALLBACK messages from the queue.
Without PM_NOYIELD, in combination with an other thread yielding
using SAL_MSG_THREADYIELD, this could re-start scheduling inside
these PeekMessage calls, resulting in various assertions inside
the scheduler code, most time due to the changed ascheduler list
in "assert( pPrevSchedulerData->mpNext == pSchedulerData )".
Change-Id: Ia96b6c0e06ffc3126b1428723b53f4b2112f8a5f
|
|
Change-Id: Id20767ff2be34a21896d3ce2b76f3944acdb1b77
|
|
Since we're filtering the wakeup timer event in the main dispatch
loop, we should use Application::Reschedule in the Backend.
Change-Id: Ie02c3533e8a6a7905281f129489e4f6f53f74692
|
|
This busy-lock happens, because user messages have a higher priority
then some system messages. What happens:
1. The main system loop picks up the LO scheduler
2. The idle worker (IW) is started
3. IW checks using AnyInput( VCL_INPUT_ANY ) for system events
4. A system event is found
5. The LO scheduler gets posted again
6. The main system loop picks up the LO scheduler instead of the
system message => goto 2
Normally it's suggested to use WM_TIMER in this case, as these messages
are supposed to have the lowest priority. But this doesn't work, if
you use PostMessage to generate them and SetTimer doesn't accept a
0ms timeout. At least PeakMessage also picks up the WM_TIMER message
before the system message, probably because PostMessage is somehow
related to the threads queue - who knows.
In the end this implements a manual, low priority event, which is checked
at the end of the ImplSalYield function. It just runs, if there is
nothing else to do. We still have to emit the timer callback event,
as ImplSalYield may wait in GetMessage, but wParam now indicates, if
it's a wakeup and can be ignored. We use the same event, so it's
easier to filter.
Thanks to Mike Kaganski for the missing information and ideas for the
final implementation.
Change-Id: Ib8e4f214ab8d3731d5594d68f38f46982c2eb36d
Reviewed-on: https://gerrit.libreoffice.org/40190
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I81ae357574e5020a5e2dfb7162d451b985c18766
|
|
There are multiple ways on Windows to yield a thread:
* SwitchToThread: yields to any thread on same processor
* Sleep(0): yields to any thread of same or higher priority
on any processor
* Sleep(1): yields to any thread on any processor
So we stay with Sleep(1), as it also seems the only call, which
actually does some sleep and is not a busy wait.
Change-Id: I85c69b2f32dba9869bbddc1a572b3a63c366c5d1
|
|
Despite precautions in Application::Execute() and ImplYield(),
in my testing I sometimes see that soffice is waiting in
ImplSalYield()'s GetMessageW() when ImplGetSVData()->maAppData.mbAppQuit
is true, so that soffice.bin hangs in the background. I suspect
that this is related to the bug. Some obscure code path seems to
be able to get here after the flag is already set.
So, test also in ImplSalYield() right before GetMessageW() to
make sure. Another possibility is that we get here when the flag
is not set yet, and gets set while already waiting, but that would
mean this happens in a different thread.
Change-Id: Idb19eabcca8b5c24eac0ca76950edc1bf1e5bccb
Reviewed-on: https://gerrit.libreoffice.org/39996
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This also adds an sal_uLong nCount parameter to
ImplSalYieldMutexAcquireWithWait, so it can be called like
ImplSalAcquireYieldMutex and actually uses the result from
the deferred DoYield.
Change-Id: Ie3b466ad03e7ed8c35a62f41c09d09757865364d
|
|
This removes a level of indirection for the timer callback handling.
It also ensures we just have a single timeout message queued.
Also drops the 16bit MAX duration limit, as CreateTimerQueueTimer
uses a DWORD for the DueTime parameter, which is always UINT32.
CreateTimerQueueTimer already sets the period to 0, which makes it
a one-shot timer, but there is also the WT_EXECUTEONLYONCE, which
enforces the Period parameter to be 0.
Change-Id: I549142394334bdc098f053b42f222b23cf4fcecd
|
|
Idles are just instant timers, which should most time have a low
priority, By dropping most special idle handling we'll just
schedule by priority.
This also reverts SalYieldResult back to a bool, which just
indicates if any event was processed.
Change-Id: Ia0b91b06dffb77af066f01838d8f9483523bf67d
|
|
1. calling Start() for invoked tasks
2. correctly schedule by priority
3. self-stopping AutoTimer
This also adds SAL_INFO output to Scheduler and Task to log the
scheduling processing tasks.
Change-Id: I3c8a708d1fd51c550320f8af3f9486c43c32e358
|
|
Change-Id: I5d4c4bb98e271e69c45b8e7f989f9b21d287c0bb
|
|
Change-Id: Ie14c4d76cb61cfbe0410103adfc1afc8ade0f3e0
Reviewed-on: https://gerrit.libreoffice.org/37146
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Those static variables had been introduced with
56c5a0ba7781a325123852737970fa7f0179ff7f "tdf#94682 limit the number of textures
for the glyph texture atlas" and dea885f80a80c6a5839ee5dbf8521487186a9522
"opengl: cache native widget textures also for Windows", but at least the
clang-cl build crashed on exit from soffice.bin with
> Exception thrown at 0x00007FFF3906AA84 (opengl32.dll) in soffice.bin: 0xC0000005: Access violation reading location 0x0000000000000898.
> opengl32.dll!glGetString() Unknown
> epoxy.dll!epoxy_glGetString_dispatch_table_rewrite_ptr(unsigned int name) Line 46456 C
> epoxy.dll!epoxy_glGetString_dispatch_table_thunk(unsigned int name) Line 46456 C
> epoxy.dll!epoxy_is_desktop_gl() Line 299 C
> epoxy.dll!gl_provider_resolver(const char * name, const gl_provider * providers, const unsigned short * entrypoints) Line 7323 C
> epoxy.dll!epoxy_glDeleteTextures_resolver() Line 14646 C
> epoxy.dll!epoxy_glDeleteTextures_dispatch_table_rewrite_ptr(int n, const unsigned int * textures) Line 45813 C
> epoxy.dll!epoxy_glDeleteTextures_dispatch_table_thunk(int n, const unsigned int * textures) Line 45813 C
> vcllo.dll!TextureState::unbindAndDelete(unsigned int nTexture) Line 59 C++
> vcllo.dll!ImplOpenGLTexture::~ImplOpenGLTexture() Line 182 C++
> [External Code]
> vcllo.dll!PackedTextureAtlasManager::~PackedTextureAtlasManager() Line 129 C++
> vcllo.dll!GlobalGlyphCache::~GlobalGlyphCache() Line 67 C++
> [External Code]
> vcllo.dll!??__FgGlobalGlyphCache@GlyphCache@@0V?$unique_ptr@UGlobalGlyphCache@@U?$default_delete@UGlobalGlyphCache@@@std@@@std@@A@YAXXZ() Line 48 C++
> [External Code]
resp.
> Exception thrown at 0x00007FFF3A5AAA84 (opengl32.dll) in soffice.bin: 0xC0000005: Access violation reading location 0x0000000000000898.
> opengl32.dll!glGetString() Unknown
> epoxy.dll!epoxy_glGetString_dispatch_table_rewrite_ptr(unsigned int name) Line 46456 C
> epoxy.dll!epoxy_glGetString_dispatch_table_thunk(unsigned int name) Line 46456 C
> epoxy.dll!epoxy_is_desktop_gl() Line 299 C
> epoxy.dll!gl_provider_resolver(const char * name, const gl_provider * providers, const unsigned short * entrypoints) Line 7323 C
> epoxy.dll!epoxy_glDeleteTextures_resolver() Line 14646 C
> epoxy.dll!epoxy_glDeleteTextures_dispatch_table_rewrite_ptr(int n, const unsigned int * textures) Line 45813 C
> epoxy.dll!epoxy_glDeleteTextures_dispatch_table_thunk(int n, const unsigned int * textures) Line 45813 C
> vcllo.dll!TextureState::unbindAndDelete(unsigned int nTexture) Line 59 C++
> vcllo.dll!ImplOpenGLTexture::~ImplOpenGLTexture() Line 182 C++
> [External Code]
> vcllo.dll!OpenGLTexture::~OpenGLTexture() Line 313 C++
> [External Code]
> vcllo.dll!TextureCombo::~TextureCombo() Line 51 C++
> [External Code]
> vcllo.dll!std::pair<ControlCacheKey, std::unique_ptr<TextureCombo, std::default_delete<TextureCombo> > >::~pair() Line 145 C++
> [External Code]
> vcllo.dll!o3tl::lru_map<ControlCacheKey, std::unique_ptr<TextureCombo, std::default_delete<TextureCombo> >, ControlCacheHashFunction>::~lru_map() Line 34 C++
> vcllo.dll!??__FgTextureCache@?A@@YAXXZ() Line 738 C++
> [External Code]
Change-Id: I0198f657f5d59314c5f662c214504ed3e1523567
Reviewed-on: https://gerrit.libreoffice.org/36801
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As it happens this DirectWrite stuff is using some thread pool
internally, and that must be shutdown before exit(), as Win32 will
terminate all other threads at that point, and then the thread pool
wants to talk to threads that don't exist any more.
https://blogs.msdn.microsoft.com/oldnewthing/20120427-00/?p=7763/
So convert this from a global variable that is deleted from DllMain()
to a member of SalData, so it is deleted from DeInitVCL().
Change-Id: I51408a07c78758cf0c193ab66b9214d0c9dbd9e3
|
|
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
since we only use the AsciiCString enumerator.
Consequently simplify the GetConnectionIdentifier method
Change-Id: I9e1a1318d2f12bfd18edeb8479e0e7171b22d0f1
Reviewed-on: https://gerrit.libreoffice.org/34026
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibe08034bcf2a73fb12562c87c2898db1e974376c
Reviewed-on: https://gerrit.libreoffice.org/31577
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I40f8a6fef9d66b28a1d72551a6873b041b38b09e
Reviewed-on: https://gerrit.libreoffice.org/29841
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
