Age | Commit message (Collapse) | Author |
|
Change-Id: If9e9371569750dd2c970450b808c6c5567faae55
|
|
Change-Id: I8a737a2f22c7be9630a1f7562b4309e687bb85f9
Reviewed-on: https://gerrit.libreoffice.org/30948
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Blacklisted intel driver for graphics card Intel(R) HD Graphics 4000 for Windows 8.
With this card LibreOffice won't start.
Change-Id: I3f4e04da7b4d61bddb1e755771b6a9538b596c51
Signed-off-by: Marina Latini <marina@studiostorti.com>
Reviewed-on: https://gerrit.libreoffice.org/30754
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I8a36234068ce0818b7baaa3b6c68d789753db6de
Reviewed-on: https://gerrit.libreoffice.org/30711
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Some intel drivers crash when areaScale shader with "large" array
is used. This adds a "reduced register" version of the areaScale
shader. We still use the first version of the shader for other
drivers and switch between the 2 implementations with a runtime
detection.
Change-Id: I1860f898c03b40a600eb1b41f7262719382a7171
Reviewed-on: https://gerrit.libreoffice.org/30571
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I755e312e3e0a69b99a8f02f7d05561b7289845ce
Reviewed-on: https://gerrit.libreoffice.org/30597
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I9ca5a97ae3ed2472257f468f6751903b458529a7
Reviewed-on: https://gerrit.libreoffice.org/30502
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
BGRA is native color arrangement on Windows however some intel
drivers have problems with large textures if they read from a
BGRA buffer. So with this commit we switch to RGBA color
arrangement. This shouldn't cause much performance differences,
but we need to convert from RGBA to BGRA when printing.
Change-Id: Ic112dc6a6c5d8b70e96041d0de15a03bbbdc406f
Reviewed-on: https://gerrit.libreoffice.org/30544
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I1876e203d3a3a5fa36d83a9b282ba49429c1da2a
Reviewed-on: https://gerrit.libreoffice.org/30261
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3ab0da9cf83e0e85b8442b34ecd6eb91dd3d1bd3
Reviewed-on: https://gerrit.libreoffice.org/27875
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I40f8a6fef9d66b28a1d72551a6873b041b38b09e
Reviewed-on: https://gerrit.libreoffice.org/29841
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie75beb4e282a4d1b784a5847262e39cf9c851527
Reviewed-on: https://gerrit.libreoffice.org/29440
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I70fcf95dfd3db05b4fd6e5cee37866f673d3afa8
Reviewed-on: https://gerrit.libreoffice.org/29183
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
Change-Id: I1f05ed32cabc059309f46ec0a195705f0e774bd6
|
|
Change-Id: Ib740da708612df7a5f4b8c82262b9b1bd436604d
|
|
Change-Id: I188570d11349a5344753f3948daedf0e17806c6c
Reviewed-on: https://gerrit.libreoffice.org/28536
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id5323cb6f52666f85965e11b07e4f2bca8af4e78
|
|
after commit 500a3be0 "loplugin:countusersofdefaultparams in vcl..xmlsecurity"
Change-Id: I09b07f241dc45f2d23370addfb1bc10aa2caedc4
|
|
Change-Id: I5710ce91e804641d4c997bc3d06970a5ed0cb5b1
Reviewed-on: https://gerrit.libreoffice.org/27890
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Ied73966633e5ffd56faccea7ec1408bd83642b58
Reviewed-on: https://gerrit.libreoffice.org/27862
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Apparently in some remote desktop situations the device string uses
"RDPDD" and not "RDPUDD". No idea what the semantic difference is.
Change-Id: I85532b90d759d02fffb73d0f3d22166aefd4edab
|
|
Change-Id: Ic8060ebdabb86d8b724ee419fdfcc1f58e8a0316
Reviewed-on: https://gerrit.libreoffice.org/27614
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
If anything fails at context creation then don't forget to
deallocate resources.
Temp window creation is written C like, as it was copy/pasted from
an C example.
Change-Id: Ia9d704e42206b1d4c37db2954bba4f165e3c8389
Reviewed-on: https://gerrit.libreoffice.org/27613
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
To get the anti-aliased polygon we draw a anti-aliased line around
every trapezoid. This works fine until we draw a transparent
polygon where the lines become visible because of blending. A much
better and faster way is to just draw the polygon outline with
anti-aliased lines. This is done with this commit.
Change-Id: Ice50e5eb3343f2c5d51ade8ad0e170043541f0ff
Reviewed-on: https://gerrit.libreoffice.org/27611
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I1b3db15b2fbdd948dcc9bacf7891f8429f066150
|
|
Change-Id: Ica3698d0dbff1ee7a1e822d2765eb4019ccef224
Reviewed-on: https://gerrit.libreoffice.org/27498
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I27ef828a8d47d50adbbcc3fb0fd152f4f6ffc446
Reviewed-on: https://gerrit.libreoffice.org/27497
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0b53c4bf5b4619cde357cf4eb432b153b1f7e6b5
|
|
Change-Id: If06fffa8db050df0f9c1c7da6163575bf522382e
Reviewed-on: https://gerrit.libreoffice.org/26754
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
When we batch a draw command we need to start the flush timer
(if not already started) as otherwise it could happen that we
won't flush the offscreen texture at the correct time or at all.
This fixes a problem with drawing of pop-up "help" text.
Change-Id: I6afcf173c3ac517ed0612cd413d95e28c19faa81
|
|
OpenGL doesn't support palettes so when the texture is created,
the bitmap buffer is converted to 24-bit RGB. This works nice for
showing the bitmaps on screen. The problem arises when we want to
read the bitmap buffer back (like in a PDF export) as we have to
convert that back to 1-bit or 4-bit palette bitmap buffer. For 4-bit
this was not implemented yet, on the other hand for 1-bit it was
implemented but it didn't take palette into account so the bitmap
was not correct (inverted).
This commit introduces a ScanlineWriter which handles writing
RGB colors to 1-bit and 4-bit palette scanlines. The class sets
up the masks and shifts needed to place the color information
at the correct place in a byte. It also automatically converts a
RGB to palette index.
Change-Id: Ie66ca8cecff40c1252072ba95196ef65ba787f4c
Reviewed-on: https://gerrit.libreoffice.org/26532
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Id377bc3bd814fad822d577603b1f147b71ad9ae2
Reviewed-on: https://gerrit.libreoffice.org/26445
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I27962119ade7bcbc20b94eb548bd2c9dfb386404
Reviewed-on: https://gerrit.libreoffice.org/26207
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I901e5de3e4e25f0cae5c71d6e83fd94459fe7b7e
Signed-off-by: melikeyurtoglu <aysemelikeyurtoglu@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/21951
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
drawAlphaBitmap didn't use a high quality scaler for scaling
the texture but used the default scaling method in OpenGL (either
GL_NEAREST or GL_LINEAR, whichever is defined when texture
is created) which are low quality scalers - especially when
downscaling textures.
Change-Id: I6236b2ee92b9e5044b176a40a444027072b09b58
|
|
Previously, when a texture atlas was destroyed we teared down
the ImplOpenGLTexture even if there were OpenGLTexture instances
around. This caused that we could try to access an already
deallocated ImplOpenGLTexture which causes a seg. fault.
Now we change this so that a FixedTexture is no different than a
OpenGLTexture - we just release the reference, so any existing
OpenGLTextures for our texture would still be valid.
An additional problem is that FixedTexture registers a callback
for slot deallocation so we know when a OpenGLTextures that holds
a specific "slot" on the texture is deallocated. However if
FixedTexture is not existent anymore, the callback still gets
triggered and is trying to access invalid memory. To solve this
we need to unregister callbacks before FixedTexture is destroyed.
Additionally improve validity of a OpenGLTexture is valid. If
ImplOpenGLTexture is not allocated (nullptr) is one case, but in
addition to that if ImplOpenGLTexture has an id == 0 it also means
that it is not valid (anymore).
Change-Id: I87346198e8928e112619da62687d5856cb8aafb8
|
|
To get polylines to draw in a batch it was necessary to refactor
the polyline code to work with GL_TRIANGLES instead of the previous
used GL_TRIANGLE_STRIP. For this and to make the code easier to
handle a new class was introduced: LineBuilder, which purpose is
to assemble vertices for a polyline (line ends, line joints).
In addition we need to know the line width, anti-aliasing (AA) per
vertex basis (in addition to color, normal and extrusion) so we
can draw many polylines with one draw call. This info is now
stored in Vertex struct which is used when drawing lines or
triangles (fills).
Uploading of vertices has also been changed, previously we
uploaded the vertices with the drawcall. a convention in Modern
OpenGL is however to use VBO (Vertex Buffer Object) for this.
With this we can upload the to the GPU vertices independently
and not upload them if this is not needed (which is currently
not used yet). A vector of Vertex structs is now uploaded to the
GPU using a VBO which is handeled with a new VertexBufferObject
class.
In addition to reduce the ammount of duplicated vertices, we use
a index vector (handled by IndexBufferObject class) where we only
define the indices of the vertex buffer which should be drawn.
Change-Id: I49dc9c6260b459f4f4ce3a5e4fa4c8ad05a7b878
|
|
Pass a SalColor by value here, too, for consistency.
Change-Id: I17ea621d376670284875d0af4830bf9c6f5da202
|
|
Change-Id: Ic14ff3235071f8300c6054000e4b0e397d7c99a3
|
|
Drawing accumulated textures (in Accumulatedtextures) is independent
of drawing with render list which causes problems with rendering
order when render list and accumulated textures are flushed. To
solve this we need to combine both so we can check for overlapped
drawing.
Previously drawRect was using RenderList batch drawing but not
drawAlphaRect which is essentially the same as drawRect but
additionally supports alpha value. This adds support to draw
alpha rectangles to RenderList and converts drawAlphaRect.
Change-Id: I82bf0b410e5ebabb13bab7b29a2e53a6fdaa404f
|
|
Change-Id: I963b1bbf322acb20bf4e21834ba9c7ae400eaf7d
|
|
Change-Id: Ie9c41f95815a57c3a9e68ce7b7b0c1e09291988b
|
|
Change-Id: Ib1619fa476f488c5315411b1ad4d1b7464c70c69
|
|
VertexUtils - collection of utils for working with Vertices.
Add deferred flush to some places directly where it is called
indirectly. This is to assure that we don't produce regressions
if we change the behavior in the future.
drawAlphaBitmap is the same as drawBitmap so when drawBitmap is
called just redirect to drawAlphaBitmap
Change-Id: Ibef1ba88865856d92d9e93734cf5d6561af785c0
|
|
We have comphelper::WindowsErrorString(), so use it, in SAL_WARNs,
right where an error happens. Get rid of the fairly unhelpful
ImplWriteLastError() function.
Avoid duplicated error reporting.
Change-Id: I83374a65980b7c0ffa35fc493b4fb1f2e94f0dbb
|
|
If we notice early enough that OpenGL is broken or not good enough, we
can disable it and terminate with EXITHELPER_NORMAL_RESTART. Not
beautiful, but works.
The earlier added check whether shader compilation and loading of
shader program binaries from a cached file works is now just one of
the aspects that are checked.
Change-Id: I9382576cc607f1916f6002f1fa78a62e23180fe3
|
|
(And not just names from the hardcoded list.) Surely we want it to be
possible to add a blacklist entry for a hitherto unhandled vendor to
the file at a user site without having to modify the parsing code and
rebuilding LO.
Change-Id: I01ca45cb91df06e1634a565b3e469fb85fe4e116
|
|
Change-Id: I12b45b499bdf2041d6b50fa85e30612916462b3e
|
|
When feather is 0.0 (used when anti-aliasing is disabled) then
we get a "division by zero" situation. As per OpenGL secs. the
shader should not fail in this situation however the result is
undetermined. Most GPUs handled this correctly but on some the
lines didn't draw at all. This should fix this issue.
Change-Id: I56ca2f10c393491807321969c72085ef7690d16a
|