| Age | Commit message (Collapse) | Author |
|---|
|
When dragging a selection box on an empty background in
Impress and only with Skia/Metal, the selection box
would not keep up with the pointer. The selection box
would repaint sporadically or not at all if the pointer
was dragged rapidly and the status bar was visible.
Apparently, flushing a graphics doesn't actually do much
of anything with Skia/Raster and Skia disabled so the
selection box repaints without any noticeable delay.
However, with Skia/Metal every flush of a graphics
creates and queues a new CAMetalLayer drawable. During
rapid dragging, this can lead to creating and queueing
up to 200 drawables per second leaving no spare time for
the Impress selection box painting timer to fire.
So with Skia/Metal, throttle the rate of flushing by
calling display on the view.
Also, with the reduced Skia/Metal flushing load from this
fix, the color conversion when drawing to an NSBox appears
to be no longer needed. The converted color appeared less
saturated, at least to me, so accept the (hopefully now
imperceptible) performance hit of drawing an NSBox with
native colors.
Change-Id: I55b4ab763bf20c6c2acad65587b703fc6f645264
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177530
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
Tested-by: Jenkins
|
|
Change-Id: Ia1395f64bdc649f8e0f450b9173d302efa058c9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177326
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
We don't draw popup menus and menubar rather use the native ones. I don't know any Objective-C which made it really difficult for me to parse the widget toolkit code.
I can learn it if required, but it would be better if some macos developer takes this patch further; Themeing related objects like colors, persona settings (TODO) will be available via the ThemeColors class.
Change-Id: Idd89328ca82fbfa58b1e686b5b105469bea4b4a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171239
Tested-by: Jenkins
Reviewed-by: Sahil Gautam <sahil.gautam.extern@allotropia.de>
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
|
|
While debugging tdf#163945, Xcode's Instruments application uncovered
the following performance bottlenecks when using Skia/Metal:
1. Very slow rendering an NSBox:
Many system colors have the NSColorTypeCatalog color type. For
some unkown reason, setting the NSBox's fill color to a color set
to NSColorTypeCatalog causes drawing to take at least twice as
long as when the fill color is set to NSColorTypeComponentBased.
So, only draw with a fill color set to NSColorTypeComponentBased.
2. Excessively large offscreen buffers when drawing native controls:
The temporary bitmap was set to the control region expanded by
50 * mScaling (e.g. both width and height were increased by 200
pixels when running on a Retina display). This caused temporary
bitmaps to be up to several times larger than needed. Also,
drawing NSBox objects to a CGBitmapContext is noticeably slow
so filling all that unneeded temporary bitmap area can slow down
performance when a large number of NSBox objects like the status
bar are redrawn in quick succession.
Using getNativeControlRegion() isn't perfect, but it does try to
account for the focus ring as well as the minimum width and/or
height of the native control so union the two regions set by
getNativeControlRegion() and add double the focus ring width on
each side just to be safe. In most cases, this should ensure
that the temporary bitmap is large enough to draw the entire
native control and a focus ring.
3. Unncessary copying of bitmap buffer when drawing native controls:
Let Skia own the CGBitmapContext's buffer so that an SkImage
can be created without Skia making a copy of the buffer.
Change-Id: Ibd3abb4b9d7045c47268319772fe97a5c4dba3c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177225
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
|
|
Replace direct access to the (currently still public)
SalFrame::maGeometry member in macOS code by using the
public getter SalFrame::GetUnmirroredGeometry, or
more specific getters for the height and width
(SalFrame::GetWidth, SalFrame::GetHeight).
Change-Id: Ic14fa480c58b09e5d0dd9ea7042d82c5f82c6eea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173956
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
|
|
This reverts commit 5ff701226b00963312cb2a78e77966d012b79c82.
Reason for revert: Tester reports no change in behavior after the commit.
Change-Id: Ic6d9f4834c7c6e3fae34d132298b335f433df280
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160470
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
|
|
When scrolling on some Intel Macs either via dragging
the scrollbar thumb or via swiping the trackpad with two
fingers, final repaint of scrollbars doesn't appear to
get flushed to the screen. It appears that scrollbars
aren't updated and repainted until after a batch of
native scroll events have been dispatched. On slower
machines, this lag is long enough that any pending
forced flushes have already been done so when the timer
that repaints scrollbars finally fires, the repainted
scrollbars won't get flushed to the native window until
the next normal flush which may not occur until seconds
later.
Change-Id: Iadef6812cd2495a28347560caae81f604c908b51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160440
Tested-by: Jenkins
Reviewed-by: Patrick Luby <plubius@libreoffice.org>
|
|
Uses NSLevelIndicator to render LevelBar control on macOS.
Closely follows the existing implementation for ControlType::Progress
Change-Id: Ibd38e172b8b6297e6322cfe9d5a1b0a6ef0f0656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158504
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
|
|
checkboxes, radiobuttons and pushbuttons look decent, focus ring works
editboxes work, focus ring doesn't for some reason, so faked that in
spinbuttons work
list and combo boxes work
scrollbars work, though with some degree of overly complicated fakery
tabpanes and tabcontrols work
sliders work
progress bars work
disclosure butttons in listtrees work
a dark mode icon theme is automatically selected under dark mode
Change-Id: I4835c7639f725a0154288440fcad400f618438e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141435
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ibc2605261de84337f4880f07a5ecb25e934c0251
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141759
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... and use it to remove a duplicate and simplify code.
Should mostly be a refactoring, which was mainly done by some
larger sed calls, except for the new API calls, which helped
shrinking some LOC. All data is also now private.
Originally two of the "replaced" "classes" had unsigned width
and height and one had signed. Noel pointed out, that during
calculations, the value might get negative temporarly, so this
now settles with signed values. Still the set size should never
be negative and this is enforced this way. Not sure that is what
Noel had in mind.
This also includes:
- rename WindowState => WindowData
- rename WindowStateMask => WindowDataMask
- rename WindowStateState => WindowState
- move WindowState and WindowDataMask to vcl/windowstate.hxx
- move WindowData(Mask) and WindowState into vcl namespace
- readability: replace or'ed WindowState enums with "meta" enums
+ add "meta" WindowState enums PosSize and PosSizeState
Change-Id: Icd16cfb498531aa7238ddbde83fcb0ed6d9e4f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135426
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
