Age | Commit message (Collapse) | Author |
|
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.
Change-Id: I7024b081b26f3545af12a3a3a038fe5e5671af3c
Reviewed-on: https://gerrit.libreoffice.org/59275
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I20c007b13dae2d1155034711ad1ad48bfdfd0ba8
Reviewed-on: https://gerrit.libreoffice.org/59288
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
checking the glXCreateContextAttribsARB function pointer will just return the
epoxy_glXCreateContextAttribsARB stub which always exists.
Change-Id: I740cc680082102c1f9712cf5cc083e92b26f8865
Reviewed-on: https://gerrit.libreoffice.org/59300
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=cd66852f6dd08631a25d15a1527a647e69ab8ce3
Change-Id: Iea4b21647dd01406271f9b3e13fea3cc73e1c801
Reviewed-on: https://gerrit.libreoffice.org/59303
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
instead of "comment" which is less precise.
Change-Id: Icca55a3c440748f311d896aac648a7a6d89f3bc4
Reviewed-on: https://gerrit.libreoffice.org/58763
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
regression from
commit 9cceba9a928cf3b3447f293020be2fe76c035ed5
make DBG_TESTSOLARMUTEX available in assert builds
Change-Id: Ifbedc3c16f341a12ba026fc598fb5386da91c50c
Reviewed-on: https://gerrit.libreoffice.org/59245
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id884bdd1f1b5314df05b4d8839b13922f19f01cb
Reviewed-on: https://gerrit.libreoffice.org/59236
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and dramatically simplify
Change-Id: If0947125cd599ca5e2d5a9dc5974a646d4bca605
Reviewed-on: https://gerrit.libreoffice.org/59222
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ife2d609403c753b917f29fa00bc5f5f1a520503d
Reviewed-on: https://gerrit.libreoffice.org/59238
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I36ffe5952e4ca930ed51fa547611ce4c7a51e1d7
Reviewed-on: https://gerrit.libreoffice.org/59237
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This means that the pre-computed glyph ids and positions are usable with
multiple dx array or draw base.
So the amount of cached data is smaller, but it can be used in more
situations, most importantly Writer's SwFntObj::DrawText() use-case
(which does GetTextArray() followed by a DrawTextArray(), with different
dx array arguments).
Change-Id: I3bcd1b7a015c2cf9921efa0f3f355f2c627fb652
Reviewed-on: https://gerrit.libreoffice.org/59207
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: If45257293e997bc4540b97fbbe5f1f4b77a48b69
Reviewed-on: https://gerrit.libreoffice.org/59202
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Don't make it the default yet, though.
Change-Id: Ida56eb25a84bf5425d4879c062c084bb68984d9a
Reviewed-on: https://gerrit.libreoffice.org/59180
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
This allows using the SalLayoutGlyphs obtained from
GenericSalLayout::GetGlyphs() to return early in
GenericSalLayout::LayoutText().
Change-Id: If3a004f983f3578915786668bfcada00227d2eeb
Reviewed-on: https://gerrit.libreoffice.org/59169
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I4d1c0ce31c4bfde0c1c681235868f6e5484fb561
Reviewed-on: https://gerrit.libreoffice.org/59174
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
OutputDevice::ImplLayout() does a number of things: first it calls the
expensive SalLayout::LayoutText(), then it does a number of remaing
tweaks to the resulting SalLayout based on the rLogicalPos and pDXArray
parameters.
This means that the resulting layout is not easy to reuse for Writer
purposes, as it typically operates with the same text multiple times,
but with different LogicalPos/DXArray.
Add a new flag that returns the glyph items early, with the hope that
this way the result only depends on the output device state and the
string only, nothing else.
Change-Id: I7c4a23d0f230495c8ba0ebbd1cfc3421e4a6e43c
Reviewed-on: https://gerrit.libreoffice.org/59159
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I30556aba4490bef7f4a6e6b3899cc05f4b6a06d4
Reviewed-on: https://gerrit.libreoffice.org/59104
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
I plan to use this in SwFntObj::DrawText().
Change-Id: Ic5e167d90a7e72452d8efa9fad06b8067675a225
Reviewed-on: https://gerrit.libreoffice.org/59108
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
ATK_ROLE_EDITBAR's nick name is actually "edit bar" (special-cased in
atkobject.h)
Change-Id: Icd4767d3513c7a5ad1774357d026922d74a42f90
Reviewed-on: https://gerrit.libreoffice.org/58762
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
although I rather suspect these FreetypeFont objects would be better
held by rtl::Reference
Change-Id: I1a7d6ca47d1f78686637368a4bec57b1fcfaa6e9
Reviewed-on: https://gerrit.libreoffice.org/59020
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idf8f843f2740bc20e6b0877b62dbfc778e31acd8
Reviewed-on: https://gerrit.libreoffice.org/59018
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id0a6a44848541968e9084a198366accda9c1149a
Reviewed-on: https://gerrit.libreoffice.org/59017
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Idf591f6d8557f1477eec4f8d69358ff41d9acff3
Reviewed-on: https://gerrit.libreoffice.org/59016
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I28f8338f5c318f2228b742e2e171d53820cb0cc8
Reviewed-on: https://gerrit.libreoffice.org/58984
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This should be used for brief non-editable text which is not meant to have a
relation with another object (as opposed to text or label).
Change-Id: I46bfa56042a51295e9fa0d332babdbb40668ff0b
Reviewed-on: https://gerrit.libreoffice.org/58734
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: If5faadee3504d88df8584850905d3b3de46c0328
|
|
so we can avoid temporary copies when appending a substring of an
OUString to the buffer. I would have preferred to call the method just
"append" but that results in ambiguous method errors when the callsite
is something like
sal_Int32 n;
OUStringBuffer s;
s.append(n, 10);
I'm not sure why
Change-Id: I6b5b6641fcb5b26ce2269f89ef06e03c0b6aa76f
Reviewed-on: https://gerrit.libreoffice.org/58666
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0bcdff1d355f374e9922cf3f318a88f01af86f4f
Reviewed-on: https://gerrit.libreoffice.org/58929
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I7c927bb46ce411138069f7c64a5036ce07077ced
|
|
Both of my GPUs failed to start with GL enabled in an enable-symbols
build, but they were fine in a dbgutil build.
It seems the problem was that in case CHECK_GL_ERROR() expands to an
error reporting code, then we already correctly checked the error of the
last GL call at the end of tryShaders() -- but in case it expanded to
nothing, then previous (unrelated) errors signaled that shader
compilation went wrong, even if it did not.
Given that we have error handling right before glDeleteProgram(), clear
the GL error queue before calling glDeleteProgram().
Change-Id: If58188d06a0b7009a71af82c476b5aa77823d9b0
Reviewed-on: https://gerrit.libreoffice.org/58852
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
what d7fc00e1f7ab7a44e6102a and 1af4ab72e2488515fcaede already does
for kde5
Change-Id: I924bdc5cfd6a12ff7bdbeef36d606c03307cb99b
Reviewed-on: https://gerrit.libreoffice.org/58832
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I4758bc5afa9f9eaced7763b9923250f27df14259
Reviewed-on: https://gerrit.libreoffice.org/58834
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
it was not a step in the right direction in 1st place. We distinguish
between main window frame (QMainWindow) and everything else (QWidget)
differently now
Change-Id: I331c9760f7616b2f199e63e5e521df74b08acc62
Reviewed-on: https://gerrit.libreoffice.org/58853
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
this is meant to solve the problem of native menu bar overlapping
w/ non-native, as well as the inability to place an object or select
text dragging the mouse cursor w/ LMB pressed
Change-Id: I29f590ebf79d1ecc7e17b402125384cf13774bf3
Reviewed-on: https://gerrit.libreoffice.org/58171
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I152482ef594c286d3c2a94cab62feff49bbf79fa
Reviewed-on: https://gerrit.libreoffice.org/58884
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This way SalLayout can be created separately (and potentially reused)
outside vcl as well. Don't reformat the moved code, so git blame keeps
working.
This is a first step towards the goal of
<https://wiki.documentfoundation.org/Development/Budget2017#Text_layout_performance>,
in the context of code outside vcl.
Change-Id: I8b40313b5fa531d3b56c153cbc4b5ca3cec8f8df
Reviewed-on: https://gerrit.libreoffice.org/58851
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
It seems the only side effect of GenericSalLayout::LayoutText() is
push_back() calls on m_GlyphItems, which doesn't happen for an empty
string input, so it's safe short-circuit this case.
Change-Id: Ia6e2865117bca60573e2874f11d3742413e9df4b
Reviewed-on: https://gerrit.libreoffice.org/58850
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Use it in the offscreen rendering case as well. Layout calls are visible
by logging the invocations of GenericSalLayout::LayoutText().
Change-Id: I9157aa56d22b6c0cee71cdaeca4d61d1c673c79e
Reviewed-on: https://gerrit.libreoffice.org/58831
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I977636eff8a2962ca248287f8733422d635f8559
Reviewed-on: https://gerrit.libreoffice.org/58833
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Otherwise we calculate the layout of the text multiple times, which is a
waste of resources. This effectively reverts commit
a4ed3d9a1ffa1b51ba4352a955c950235f099fdc (tdf#115353 Status bar: no
cache in settext, 2018-03-01).
That seems to be safe, given that I can't reproduce tdf#115353 after
this change, and reading through the comments the bug was reported fixed
after both the mentioned commit and
commit 8d42909cd326cb26d8ba1fb383b5578f820c72ed (tdf#115353 layout fix,
2018-02-23). So either the first one was not necessary, or it just
worked around an underlying problem that has been fixed in the meantime.
Change-Id: I79c014e9ce41be0c06dae65b5195a23d0d88c2aa
Reviewed-on: https://gerrit.libreoffice.org/58830
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Primary as a debugging measure to compare output for Qt5Graphics.
Checks mpToolkitName, so we just disable it for qt5 not kde5.
Change-Id: Ib7a67c4bec16d81dd87b6351ba106f655d37948b
Reviewed-on: https://gerrit.libreoffice.org/58790
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
So nTransparency is actually also in percent, i.e. max is 100,
instead of the full byte range, like alpha colors in Qt and VCL.
Fixes "SAL_USE_VCLPLUGIN=qt5 ./bin/run vcldemo --show poly"
transparency.
Change-Id: I723cbb2d6b5af4a37b18d3e6a5e0c5b81421221a
Reviewed-on: https://gerrit.libreoffice.org/58789
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
This is all QStyle based. Font handling still to do.
Change-Id: I784e64aa88d013146e2c9a07051a0a76a1369ff0
Reviewed-on: https://gerrit.libreoffice.org/58788
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I2a8375eb35c86c445d04f71755aef0cdbb051024
Reviewed-on: https://gerrit.libreoffice.org/58802
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@pardus.org.tr>
|
|
Change-Id: I59c5499586c16768afde822cd6d580540d1bcd73
Reviewed-on: https://gerrit.libreoffice.org/58764
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0308ddd467ab6e283c0503f98885a248eb28290c
Reviewed-on: https://gerrit.libreoffice.org/58738
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib734b3d578f8036182a2f3e22eb1f3f8951b7fad
Reviewed-on: https://gerrit.libreoffice.org/58699
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
Change-Id: I65836b437bbc27d4f6a5862fe436397d858564a2
Reviewed-on: https://gerrit.libreoffice.org/58701
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
|
|
Change-Id: Ibd50fa73a5ee63e3375ef0518df0ba84bf6fce1c
|
|
The native painting code in the kde5 backend is Qt based only.
To prevent multiple inheritance, it's moved into an extra class
and just leaves the backend specific QImage blitting in the
specific SalGraphics implementation.
Change-Id: I3d5f58f42a37966794541fe1214c1b9557376a98
Reviewed-on: https://gerrit.libreoffice.org/58652
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|