Age | Commit message (Collapse) | Author | Files | Lines |
|
Using vdev's associated with old contexts, is un-necessary and a
recipe for context switching & hence flicker.
Change-Id: I37ed967a7816e5ca0240908ab4793ce1e68570ee
Reviewed-on: https://gerrit.libreoffice.org/18602
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I5c4021c9cb3fdeace7f7d99d580dc7fe2f7c354a
|
|
Change-Id: I416734c7c42709438e3bdcdb8922ce4ec576c95a
|
|
Avoids a rather horrible flickering problem in GL mode.
Change-Id: Id205f28de209dc2e4fb6d6fa48b86ee5bd38835d
|
|
Change-Id: I1c501671d72edd5b998e80c7fa1e91dbeb507af8
|
|
Change-Id: Ibfb5ae40edd0db1f6b99bd5178d4d871ede37d7d
|
|
with the variadic variants.
Change-Id: I4499569f73b04cc7444787d51bf804c090a5c951
Reviewed-on: https://gerrit.libreoffice.org/18478
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
When there was no modification to the document, and .uno:DefaultBullet was
sent, we have got an invalidtion of the entire document.
It seems that Invalidate() was not supposed to be called in the Validate()
call, and instead, we should rely on what the Validate() invalidates :-)
Change-Id: Ia65df90e4ff34078b59c1b2eb1ce1faac790b40d
|
|
and remove unused maChildEventListeners
Change-Id: I845a9af608c3429cf9ccb0e8041f24f423839513
|
|
Change-Id: I603463d0486d4d0f21ebbdc6eca900db58bb090f
|
|
Change-Id: I121f133513a9897f38bd87be96c2cea39fbfc836
|
|
Change-Id: I3127752785b77672d37f99bc9eaa881377dabe7c
Reviewed-on: https://gerrit.libreoffice.org/18431
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ifed1a8cfa774225cb450bb211b1b1b949ef02811
Reviewed-on: https://gerrit.libreoffice.org/18429
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I2f36a123662488ef5534f7bf0845d61e497fb0ec
|
|
Previously we would get an explicit ~OpenGLContext - and potentially
leave FMR's around for other OGC users, now we treat the other users
properly - we need an explicit dispose() to get Window::dispose ordering
right.
Change-Id: I5edcbd73399b6db3dbcfb391570f364f9ab0c70d
Reviewed-on: https://gerrit.libreoffice.org/18412
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
gltf rendering, OpenGL canvas, GL transitions & GL capable (charts)
Avoid GLX operations on un-initialized contexts.
Change-Id: I7f523640f66ab656896181e5c865879234f6640e
|
|
Change-Id: I3176933d20dce9f595fd6a9c0ee434a3709fa560
|
|
Change-Id: Ic8065d4f656d42f1e2e7d8b4c602010fa0ae2d34
|
|
Change-Id: I2136c3db2742afcb4722f69297276bea1e0119f4
Reviewed-on: https://gerrit.libreoffice.org/18306
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
...the two consecutive writes to nX had been like that ever since the code
block's inception in 4716735ba7d0ad133ff018481f94d6b4f201bbd9 "#103362# improve
positioning and resizing of system windows," so assume the first one is indeed
unnecessary.
Change-Id: I52a9a8a15fa38a0d14f9e521e15b7f71013f46c0
|
|
...at least since the commented-out code using it got removed with
99f58dc2a6d9d2976948b2fe01b1ed1ae63d685e "vcl: remove dead code and useless task
comments from winproc.cxx"
Change-Id: Idddd3af6d667370cb937aa065382c1913ab8e911
|
|
Change-Id: I8bea5ac685b0076649412bd95501461242797d77
Reviewed-on: https://gerrit.libreoffice.org/18266
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I4888d0474199bb10ca81d1ad03118a150f574671
Reviewed-on: https://gerrit.libreoffice.org/18235
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I52158729d240ca3cb9e7977bc6d1f5acb14437ad
|
|
Change-Id: I69c2c27af718b1d3ff35348a69d8b57914e5ae82
|
|
Change-Id: I677f47f6b60271dc56c9d3d123cf982c00866eb9
|
|
Change-Id: I13f10bda985d55d419a5bff481130a456ae2db8a
|
|
...at least while MenuWindow is mostly a TODO still;
and ImplHanldeHelpEvent can be protected
Change-Id: Ice0bb37e7e774e51445a9d78b2cf5eaba12f6341
|
|
Change-Id: I5be4cfb951100d36054e409043cb9becbe52338d
|
|
Change-Id: Ibeace7ce7621033cf04e3186c212bbb4a27492a1
|
|
Change-Id: I2801f54cecf9c8b7d43f8e1c1699cfd7fdd918e3
|
|
...which had apparently been unused ever since the function's introduction in
86ef4422bc62f912f72c0bedda47ce0e6e2722e4 "INTEGRATION: CWS onlineupdate3," even
though the function's code had always been careful to clip the value to
m_aAddButtons.size() (which was now detected by clang-tidy's
clang-analyzer-deadcode.DeadStores)
Change-Id: Ic3542aaef04d059125d997cdc5e199d5edb1184a
|
|
Change-Id: Ie80dfb003118d40741549c41ebcc7eda4819f05b
|
|
See (short) discussion on the mailing list, "How was it again, is the
DbgDialog useful?".
Change-Id: Ibde1eb13f16edf94f1f7aebd0befd1b0b171d5c4
|
|
If in some cases we don't want a visible separator, I can't
understand why it shouldn't apply also to platforms that
support native separator drawing.
Change-Id: Ib88bece62cfbb092808f3257a7ba9bd63f4cb1d7
|
|
Change-Id: I83396e7c90d3b182f353a77c9bdf06fd17af92a1
|
|
This allows applications to request enabling/disabling of
double-buffering of their VCL frame and all its children. It works
after-the-fact, too: so in case the start center creates the frame and
later that frame is reused for Writer, then Writer can turn on
double-buffering, still.
From a user's point of view, this means that next to
VCL_DOUBLEBUFFERING_FORCE_ENABLE, there is now also a
VCL_DOUBLEBUFFERING_ENABLE environment variable that enables a safe
subset that is not supposed to draw directly at all. Enable this for
Writer only, for now.
Change-Id: Ie2cbf7d467eae2cee37fb58a1efc0a8984204408
|
|
The intention is that currently double-buffering is either enabled
globally or not. Double-buffering is known to be working in Writer, but
not in other applications, so it would be nice if double-buffering could
be also half-enabled: only in the applications where it's known to work.
For that, we need to differentiate between "we have a buffer" (supports
double buffering) and "we want to have a buffer if possible" (double
buffering requested).
Change-Id: If48d6dc0ddf5841497e78b856d803cc8abf23ac9
|
|
Polygon is one of these names that Clash with some system objects
A similar work has been done earlier with PolyPolygon.
Change-Id: Icf2217cb2906292b7275760f1a16be0e150312f5
Reviewed-on: https://gerrit.libreoffice.org/17789
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Usually the topmost window of a paint hierarchy has a paint rectangle
that covers the paint rectangle of all its children, but this is not
necessarly true in every case. One example is the cursor travelling
described in the bug report, where the topmost DockingAreaWindow only
paints a few buttons on the toolbar, and then even if children are
painted correctly to the frame-level persistent buffer, only the
DockingAreaWindow part of the buffer is copied to the screen.
Fix this by building an union rectangle that covers all areas in a
buffered paint run, and then paint that rectangle from the buffer, not
just the paint rectangle of the topmost parent.
Change-Id: Ib0b30413d83c4b3fdec27fa7ddad16c21fd094b6
|
|
Change-Id: I79a889c68e91712d2abdacc559c78813f730e623
|
|
Instead of painting on the vcl::Window directly, take a
PaintBufferGuard, and use the vcl::RenderContext of it, that may be
either the vcl::Window or the toplevel frame's buffer.
Trigger the paint of the buffer by informing the guard what area was
painted. In case of direct painting, both the ctor and the dtor of the
guard is a NOP.
This means that finally we can also assert Invert() calls on the output
device, so that direct paint can't happen when double-buffering.
Change-Id: I0322563369dc63b3c49061cbe7c4a911cb13a2e2
|
|
The motivation is that this way vcl::Cursor will be able to reuse it.
Change-Id: I7e89d5acb5d63d3297d7c3c8050ccd2172c8608d
|
|
Change-Id: I4bafba3d99fc45d6d5fa875a91d498518d3a0c29
|
|
Change-Id: Ic45f65d10835eb39b6709e7adeed1392905ea631
|
|
I did not notice this before, as my user profile had a custom window
size; but with an empty user profile the buffer had a 0,0 size, so the
buffered result was empty, as no ImplHandleResize() was invoked.
Change-Id: Ie299ad1323944941afc407dc90f2459d72885d42
|
|
This used to be necessary, but now that the "copy settings from the
window to the buffer" is always guarded with PaintBufferGuard, it's
actually one of the places that do modify the buffer settings without
undoing that later.
Change-Id: I7fde878635ffc7de7027d6d8f8de47935fc4870e
|
|
Change-Id: Ifd6a75c4312f93c815f5d137f515724f3629fa0d
|
|
If the buffer is persistent, then any member we change on it, so it suit
our needs have to be undone once we're done with the painting.
Change-Id: I7c5491b3b27601fb367af0856ac95cc3f845647a
|
|
In case we had a toplevel window W1, the paint was triggered for window
W2 and we had a sub-widget W3, then previously the buffer was created
for W2, so the pixel offsets had to be set relative to W2 when rendering
W3. As a consequence, if a single window was painted, then it was
always painted in the top left corner.
Now that the buffer is persistent and is always created for W1, make
sure that we paint to the correct offset, and W3 is always painted at
the same offset, regardless if it was painted directly, or just because
it's a child of W2.
With this, the buffer conents is closer to what is on the screen, even
if it's not perfect yet.
Change-Id: Ibf0e89ad18e5763bd2a01e69d91da163c24a309d
|