summaryrefslogtreecommitdiff
path: root/vcl/inc/impglyphitem.hxx
AgeCommit message (Collapse)AuthorFilesLines
2022-05-11fix HB_GLYPH_FLAG_UNSAFE_TO_BREAK for RTL in cloneCharRange() (tdf#148954)Luboš Luňák1-0/+1
I got the meaning wrong, when the docs talk about beginning of a cluster, that refers to text, not glyphs, so this needs to be backwards too. Change-Id: I12ef775b033100405e3332d5611844cefb6b5a85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134173 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-14compute subset of glyphs in SalLayoutGlyphsCache (tdf#139604)Luboš Luňák1-6/+27
When OutputDevice::ImplLayout() computes glyphs, the result is always the same for the same string (and font etc.), and if the function is asked to work on just a subset of the string, the returned glyphs are often also a subset of glyphs for the full string. Since e.g. EditEngine breaks text into lines by first laying out a full string and then repeatedly calls the same function for a subset of the string with increasing starting index. So if the full result is cached, it's faster to just make a subset of that, adjust it as necessary and return that, instead of doing a layout again. This requires support from harfbuzz to tell us if it's safe to break at a given position, and HB_GLYPH_FLAG_UNSAFE_TO_BREAK is that (https://harfbuzz.github.io/harfbuzz-hb-buffer.html#hb-glyph-flags-t). I'm keeping the optimization for tdf#144515, as avoiding the extra layout altogether is still useful. Change-Id: I33f70f9af89be79056e464908eac0861f58d274a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132753 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-09no public data members in GlyphItemLuboš Luňák1-6/+12
Change-Id: Ib5911a8ad33aefffa972f583c2b5fc7d42a2b9bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132746 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-09sal_GlyphId is internal to VCLLuboš Luňák1-1/+1
And can't be put into impglyphitem.hxx, as then it would have a circular dependency with fontinstance.hxx . Change-Id: I57289fa5433851f095f7b73ce842ba5a0e8497ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132745 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-12keep positions as DeviceCoordinate within SalLayoutCaolán McNamara1-2/+2
Change-Id: I20bbb0e252ffd09901f587599430e715dbe977b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128300 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-11-30remove duplicated VCL_DLLPUBLICLuboš Luňák1-4/+4
The class itself is already VCL_DLLPUBLIC. Change-Id: Ic1c352ebce8fbee4602ddc84b2db22eb0038b5e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126075 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-25replace friend access with functionsLuboš Luňák1-7/+6
Change-Id: I11cb916285c72f7cd85ea5d5c943f23d0a4f6bc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124148 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-03pull duplicate field out of GlyphItemNoel Grandin1-12/+10
we already store it in SalLayoutGlyphsImpl Change-Id: I772c08966572e42789bcede1a148b2b7710f29d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121602 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-03pack GlyphItem structNoel Grandin1-20/+20
56 bytes -> 48 bytes Change-Id: I30d9763162b701e3d07a153deae3f5e03c290393 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121583 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-24loplugin:unusedmethodsNoel1-1/+0
Change-Id: Id54e7545b3a69e03c29daf9d372bbf605312f547 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113036 Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2021-03-21reuse also font from cached SalLayoutGlyphsLuboš Luňák1-1/+1
Change-Id: Ie85c7891cf65699529e0cc08746450bb3bc0aedb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112773 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-17make SalLayoutGlyphs work with MultiSalLayoutLuboš Luňák1-4/+3
Code that needs to lay out texts repeatedly can cache the result of SalLayout::GetGlyphs() can reuse it. But GetGlyphs() returns nullptr for MultiSalLayout, so caching for it doesn't work. Worse still, it actually increases the number of layout calls, because there's the initial layout for caching and then each call will need to do the layout again because of the nullptr that's not cached. This commit changes SalLayoutGlyphs to possibly include multiple SalLayoutGlyphsImpl objects, one for each SalLayout handled by MultiSalLayout. Changes include making GenericSalLayout work directly with the Impl class, which avoids an indirection and simplifies code. Change-Id: Ic4b19934a8a06d4955b51527fe3777c5e91107b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112590 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-11-28Drop unnecessarily user-provided ~SalLayoutGlyphsImplStephan Bergmann1-1/+0
...thereby avoiding -Wdeprecated-copy-dtor when the implicitly-declared copy assignment op is used, but whose non-deleted definition was deprecated because of the user-provided dtor Change-Id: I9c4adc4b9ad0634c0afe5a4a707cc3697dbfae32 Reviewed-on: https://gerrit.libreoffice.org/84020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-17loplugin:unusedmethodsNoel Grandin1-2/+0
Change-Id: Ie2285f64919d1c83b0a8df4ceb827f731e5cd609 Reviewed-on: https://gerrit.libreoffice.org/75739 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-06Constify GlyphItemJan-Marek Glogowski1-26/+51
This hides all the data, which shouldn't change after init. Real const makes a lot of problems for copying, so this is the 2nd option to just add getters for private data. While at it use typed_flags for the GlyphItemFlags. Change-Id: Ic1eeabe2398f6c30080fdd516285b72c620b11be Reviewed-on: https://gerrit.libreoffice.org/75147 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-03-22Related: tdf#124109 vcl: make glyph item caching work with kashida glyphsMiklos Vajna1-0/+2
This was broken because GenericSalLayout::LayoutText() sets the SalLayoutFlags::KashidaJustification flag as a side-effect of building the glyph list. So in case we cache the list and not build it, the flag will be missing. This means that later in GenericSalLayout::ApplyDXArray() kashida glyphs won't be inserted. With this, the workaround in sw can be removed. Change-Id: Ic18211bf50ca673daa238e8950a381915e4b3096 Reviewed-on: https://gerrit.libreoffice.org/69566 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-03-11merge SalLayoutGlyphsImpl and SalGenericLayoutGlyphsImplNoel Grandin1-19/+9
Change-Id: I5697d2b7961ce714835316879610f23aeabbd8ec Reviewed-on: https://gerrit.libreoffice.org/69030 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-01tdf#121030 invalidate referenced FontInstancesJan-Marek Glogowski1-1/+5
This sets the FreetypeFont pointer of the FreetypeFontInstances to nullptr when clearing the cache. And it changes the interface functions of SalLayoutGlyphs to some variant different from std::vector. I don't know if we should prefer the mutable or the const font instance. With mutable at least one can invalidate the font instance when checking the IsValid(), so we can get rid of our referenced font instance. Change-Id: I6070cfcb3c549dbad3383bd4ec2b05b30645b753 Reviewed-on: https://gerrit.libreoffice.org/62688 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2018-10-30Move SalGraphics glyph functions into FontInstanceJan-Marek Glogowski1-6/+6
As we already rely on the GlyphItem's font instance, consequently this removes the SalGraphics GlyphItem based functions. Also unifies the glyph bound rect cache handling. An interesting aspect is the rotated glyph bounding box handling moved from CairoTextRender to FreetypeFont. It doesn't look like an implementation detail for Cairo, so it may have been a bug. Change-Id: I81bbb5d8ee98fb77a1eee05568c456f9e4553023 Reviewed-on: https://gerrit.libreoffice.org/62503 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-10-30tdf#120982 add font reference to SalLayoutGlyphsImplJan-Marek Glogowski1-3/+21
Now that we store the LogicalFontInstance instead of the fallback level, it's not enough to keep a pointer in the glyphs in SalLayoutGlyphsImpl. We also need a reference to the font, to keep the font instance alive. Change-Id: Idc99cf9259af6be672a97ab2c67dbffd9cf29c70 Reviewed-on: https://gerrit.libreoffice.org/62520 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-10-30Hide SalLayoutGlyphs detailsJan-Marek Glogowski1-6/+70
Nobody outside of VCL should deal with GlyphItems. Change-Id: Id84b0f320bc49f790658f23efe129b92262c2aea Reviewed-on: https://gerrit.libreoffice.org/62446 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2018-10-30Rely on the font instance of the glyphJan-Marek Glogowski1-0/+40
The FreetypeFont might already have released the font instance of the glyph, but the glyphs font instance must still be valid, so use this instead to cache glyph bound rect. For whatever reason the Windows compiler doesn't accept inline functions in the GlyphItem struct and wants to export them in the DLL, even when declared VCL_DLLPRIVATE, so this just uses static inlines as a workaround. Change-Id: I4539d91a846a54a05f9648638494e1e99f704b0a Reviewed-on: https://gerrit.libreoffice.org/62425 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 05:54:47 +0000