4
submitted 1 month ago* (last edited 1 month ago) by LeninWeave@hexbear.net to c/technology@hexbear.net

cross-posted from: https://hexbear.net/post/6598439

Cross-posting my own post from /c/feedback to /c/technology, because it seems like the feedback comm is bugged.


There has been discussion recently about the performance of the emoji picker. I wanted to make a follow-up thread.

To establish context, there are two emoji pickers.

  1. The one that appears when you type ":" followed by a string to filter the results. I will refer to this as the "inline" picker.
  2. The one that appears when you click the "Emoji" button above the text entry area for a comment/post. I will refer to this as the "popup" picker.

Many people have had performance issues with these pickers. Some have proposed reducing the number of emoji, which I am personally strictly opposed to. I think the emoji are a crucial part of this website, including the very rarely used ones. It seems much better to first pursue technical solutions to this problem.

  1. Lazy loading of the images, meaning that only the images matching your search string will be loaded rather than all the images at once.
    • @makotech222@hexbear.net implemented this, which works well. However, it seems to work only for the inline picker and not the popup.
    • Could this be implemented for the popup? I assume the popup uses a 3rd party library, which may complicate this.
    • This should theoretically allow a functionally unlimited number of emoji.
  2. Some of the images (as @WhyEssEff@hexbear.net pointed out) are oversized.
    • Perhaps these could be bulk resized. This was discussed in the previous thread.
    • I would like to also propose very low resolution versions (32x32 or similar) be created to act as thumbnails for the popup picker, if possible. This may not be worth the effort, or do more harm than good.

I have also noticed other problems with the pickers.

  1. The popup picker and inline picker seem to use different filtering algorithms, which do not provide the same list of emoji for the same input. I personally find the popup picker to work better.
  2. The popup picker seems to insert emoji at the end of the comment/post text with a space before and after.
    • This means having to remove one or more spaces when combining emoji.
    • This also means having to cut and paste the inserted text if the desired location was not the end of the post/comment.
    • I propose that it would be better for the emoji text to be inserted at the location of the typing cursor, without spaces before and after. This is only for the popup picker, it makes sense for the inline picker to insert a space after because it functions as autocomplete.
top 9 comments
sorted by: hot top controversial new old
[-] CommunistCuddlefish@hexbear.net 2 points 1 month ago

Disclaimer: I am not a web dev I am not a web dev I am not a web dev. Nothing I say should be taken as anything more than slightly educated conjecture.

I have a quibble with point 2, everything else looks like a good summary: I have not yet been convinced that image sizes are the bottleneck. My experience with optimizing code to run faster was that we needed to use some profiler built into the IDE, run a test, and it gave a trace of every function and how long it took to run or how many resources it took to run. This was something in C++ 4 years ago with a senior developer to hold my hand. I have no idea how we'd test this for Hexbear. But I think it would be prudent of us to identify what the actual performance bottleneck is before making fixes, or we may mess something up with no benefit (e.g. resizing all the emojis only to find out that the sizes make no discernible difference).

Please see this comment and its children: https://hexbear.net/comment/6632467

Edie mentions that "Loading is slowed down by each emoji being its own HTTP call"

Redwizard mentions that there are 2700+ emoji and at full resolution they add up to about 2GB, and that a lot of gifs could be converted to animated pngs to reduce their size.

From these comments it's not at all clear to me if the issue is # of emojis, size of emojis, both, or neither (neither, because it's possible there's something else at play here.)

[-] CommunistCuddlefish@hexbear.net 2 points 1 month ago

OH FUCKING GREAT I DIDN'T TEST THOROUGHLY ENOUGH BEFORE I MADE MY POST.

Inline picker: Lazy loading change made it work great, popup picker still abysmally slow.

Private browsing window where my extensions are disabled: Popup picker still slow but way way way faster than before. It's got to be one of my extensions causing the problem on my end. I'll test more tomorrow to isolate which one.

[-] CommunistCuddlefish@hexbear.net 1 points 1 month ago* (last edited 1 month ago)

Culprit Found: I had a Malwarebytes extension that was slowing down the emote loading. Removed it and it's markedly faster now.

[-] CommunistCuddlefish@hexbear.net 1 points 1 month ago

NoScript on: emotes load quickly angel-biblical-shh

[-] CommunistCuddlefish@hexbear.net 1 points 1 month ago* (last edited 1 month ago)

uBlock Origin on: emotes load quickly, both inline and popup Care-Comrade

[-] LeninWeave@hexbear.net 2 points 1 month ago

I have not yet been convinced that image sizes are the bottleneck

I don't think that they are, but there are outlier emoji (as WhyEssEff pointed out, older ones) which are larger than normal and should be resized for consistency even if the benefit to average performance is not very large.

I think that the core issue is how they are loaded. With lazy loading implemented in both pickers, I don't see a reason we could not have a functionally unlimited number of emoji. In the popup picker, I never have more than a few dozen emoji once I have entered my search string - the list doesn't even overflow the size of the popup.

[-] CommunistCuddlefish@hexbear.net 1 points 1 month ago* (last edited 1 month ago)

In light of https://hexbear.net/comment/6637743

It looks like the only real bugs that are worth attention or effort are the last two you note: standardizing the different filtering algorithms, and the popup picker inserting emoji at the end instead of where the cursor is. If WhyEssEff wants to resize images for standardization reasons that's fine, but it is not a performance issue. LeninWeave, you noted that lazyloading is working much faster for you as well so that's great.

[-] LeninWeave@hexbear.net 1 points 1 month ago

It looks like the only real bugs that are worth attention or effort are the last two you note: standardizing the different filtering algorithms, and the popup picker inserting emoji at the end instead of where the cursor is.

@makotech222@hexbear.net @BoarAvoir@hexbear.net Do you have any ideas about these two issues?

  1. The popup picker and inline picker seem to use different filtering algorithms, which do not provide the same list of emoji for the same input. I personally find the popup picker to work better.
  2. The popup picker seems to insert emoji at the end of the comment/post text with a space before and after.
    • This means having to remove one or more spaces when combining emoji.
    • This also means having to cut and paste the inserted text if the desired location was not the end of the post/comment.
    • I propose that it would be better for the emoji text to be inserted at the location of the typing cursor, without spaces before and after. This is only for the popup picker, it makes sense for the inline picker to insert a space after because it functions as autocomplete.
[-] BoarAvoir@hexbear.net 1 points 1 month ago* (last edited 1 month ago)

The popup picker and the inline picker are both external js libraries lemmy-ui uses, with varying degrees of customizability. The inline picker uses "tribute", a JS library meant mainly for things like @mentions, and the popup is a component called "Emoji Mart". I have looked at the search code for the inline picker and found it is pretty simplistic so I'm not shocked that you'd prefer the emoji mart (I haven't reviewed that code).

Totally agreed about the emoji mart popup inserting at the end. I don't know how easy or hard that change will be to make but it would be a welcome one for sure.

I also think we could still improve loading performance on emojis, though mako's lazy loading change helped a lot. They don't generally change, so they can be cached pretty aggressively, it's just been challenging to get that working right.

this post was submitted on 31 Oct 2025
4 points (100.0% liked)

technology

24123 readers
345 users here now

On the road to fully automated luxury gay space communism.

Spreading Linux propaganda since 2020

Rules:

founded 5 years ago
MODERATORS