Created attachment 169588 [details] Blank Insert Emoji drop-down Using the Tabbed interface, if we go to "Insert" and then "Emoji", the drop-down list is blank (as shown in the attached image). This happens in LO 7.0.4.2. Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 16; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.0.4~rc2-0ubuntu0.20.10.1~lo1 Calc: threaded The issue persists in LO 7.2 alpha built from source.
Thank you for reporting the bug. I can confirm that the bug is present in Version: 7.2.0.0.alpha0+ (x64) Build ID: ecb916667b633f8647790e040226b093760e6cfe CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
I'd like to report an update on this bug. The problem is not that the Emoji Selector is blank, but rather that it takes a long time to load and respond. For example, when you click the Emoji Selector, it takes around 10 seconds for it to load in my PC. After that, all actions you perform on the Emoji Selector also take a very long time to take effect. Also, if you open the selector, wait for it to show the emojis, and then close the selector and open it again, the load time will still be 10 seconds. Another problem is that objects containing emojis (for example, a textbox in Impress with an emoji in it) become very slow and unresponsive. Dragging them or applying formats take way longer than usual. In short, I believe the problem has to do with code optimization, because the current implementation is too heavy.
Created attachment 174782 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
Noel: I attached a Flamegraph here, thought you might have some ideas to optimize this.
Can not confirm, loads on Windows (which now have a correct path as for bug 105689) are immediate. The widget is using os/DE font mapping, i.e. Segoe Emoji, for the toolbar split button and grid. But each grid populates immediately, with fall back to EmojiOne Color as needed. Actual pick and placement onto document canvas is the expected EmojiOne Color (in a b/w glyph outline as expected). Text run for placed Emojis can be selected and the font toggled to MS Segoe Emoji, which is now rendering to canvas as color glyph--but think the color glyph support is Windows 10 only. Anyhow, great to have the path fixed for Windows builds--maybe it can come out of 'experimental' finally? Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4cd3ce9848aa039b8d443a1257d1298231680b01 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to V Stuart Foote from comment #5) > ... > Anyhow, great to have the path fixed for Windows builds--maybe it can come > out of 'experimental' finally? > ... I responded on https://gerrit.libreoffice.org/c/core/+/121738, so I put tdf#144348 in See also.
Created attachment 176753 [details] Screen capture showing the problem This bug still persists on LO 7.3 beta 1. I uploaded a video showing the current experience using the Emoji Selector. Notice the following issues: 1) It takes a very long time to load 2) After it is loaded, clicking will have no results. For instance, when the user clicks an emoji, it should get selected, which does not happen 3) Clicking emojis cause them to be entered in the text box, but the characters are only shown when the user clicks outside the text box; the characters should appear as they're selected. Additionally, after loading the Emoji Selector for the first time, if I close it and open the Emoji Selector again it will still take a long time to load.
Still slow in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: cb83063cc0eb4e93bd44bc0cb9b7c4841230cdef CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
*** Bug 136922 has been marked as a duplicate of this bug. ***
It seems that most of the time is spent in glyph fallback, which matches my experience that the font the emoji widget sets is unused and the default font is used and then glyph fallback is used to select fonts with emoji and this seems to be extremely slow on Linux.
The EmojiControl is gone (bug 151197).