osc.lua: extract icon_font and icons variables

[guidocella]

osc.lua: extract icon_font and icons variables

Define the icon font and icons in variables instead of scattering them throughout the code to make it easy to change them in the future, or for forks to change them. Also put the hex values in comments to easily compare which icons in the font are unused, and explain how to get the decimal values of the bytes.

Copied from ModernX.

TOOLS/mpv-osd-symbols.sfdir: remove unused icons

E003 is a stop icon that was never used
E010 to E013 are the progress bar icons removed by ef3c0e6
E111 is a duplicate of the icon to exit fullscreen, E109

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[kasper93]

Can we align = vertically?

[guidocella]

I thought of aligning them but assignments in other tables in the file are not aligned, do you want to align only this one?

[kasper93]

it would look nice with constant value length, but whatever. avih also don't like aligning

[na-na-hi]

Removing glyphs can affect third party scripts which use them for rendering icons. I also don't see a reason to remove the stop icon, as it's a common functionality and likely that some UI changes will use it later.

[kasper93]

Should we remove support for puc lua?

[avih]

Should we remove support for puc lua?

I think we really shouldn't.

luajit is a project with a bus-factor of 1, highly non-hackable, and way way more complex code than puc-lua (5.1 or 5.2).

Such a core part of mpv (lua scripting) cannot depend on one person to release sources which build correctly on every platform which mpv supports.

[guidocella]

I would be in favor of dropping support for Lua 5.1 because it makes you waste a lot of time converting unicode code points (I have the same issue in my LRC script) and the performance improvement of LuaJIT is nice for fuzzy finding, it will matter even more once history search is merged since that can grow infinitely. If LuaJIT is abandoned we should switch to Lua 5.4.

[avih]

I would be in favor of dropping support for Lua 5.1 because it makes you waste a lot of time converting unicode code points

Surely you don't need to do that more than once, because at least this comment was about literal codepoints embedded in literal strings as part of the script soure code, and that wouldn't change with each iteration of any loop. And if you do and can't avoid it and have to do whatever a lot, then write the slow part in C.

Using luajit is not a magic solution. because even if it's 5x faster with luajit, you run it on a RPI and it becomes x5 slower again.

It's a script, it can't be expected to perform like C code. But before that, do ensure your whatever algorithm is efficient, because typically it should be enough to gain the speed you prefer.

Also, IIRC 5.1 and 5.2 perform similarly across different use cases, from my own local tests in the past (sometimes one is faster than the other, but it's not necessarily always 5.2 which is faster, and largely they're similar).

And it's better to support more than once version, so I think we should keep both.

it will matter even more once history search is merged since that can grow infinitely.

Something which can grow indefinitely doesn't sound like a great idea to me. Surely you can drop some years old historical commands which you once issued accidentally. So pick a reasonable limit and a useful search algorithm, and it should be OK, and if not, again, write it in C, or drop this feature.

It's a script. Don't push it beyond reasonable limits.

And one can't expect minimum absolute performance (e.g. "this must finish in under 5ms"), because it can run on a wide range of processors, and an inefficient algorithm will remain slow regardess of the processor (or scripting VM), especially as the input grows.

So keep the runtime linear as much as possible with the input size, or at most log-linear, ensure each iteration is reasonably efficient, and then ensure the input size is also within reasonable limits.

That's how code works. When the input becomes big, the algorithm and implementation matter more than the absolute performance of each line of code, and limits should be put in place.

[guidocella]

I was talking about the watch history. It is up to users when to clear that. I did suggest integrating the C version of fuzzy search iniitally but it was rejected in favor of a Lua script because that was smaller.

[guidocella]

By the way, these were my measurements last time I tested it for calling fzy when typing 1 letter in the g-r selector (10k properties):

lua 5.1: 0.166s
luajit: 0.08s
C: 0.005s

[avih]

lua 5.1: 0.166s
luajit: 0.08s

If I got that right, luajit ended up 2x faster than 5.1? IMO that's a pretty small diffrence in the grand scheme of things. Definitely not enough to consider dropping 5.1. (yes, I know luajit can be much faster than 5.1 in some cases, but you always need to look at the overall gains, and not through the needle hole, and in the big pictures there are typically many more factors than how fast one function runs).

Also, I didn't look at the code, but there might still be room for further improvements. Usually there is, but not always enough of it to warrant the additional effort and possible complexity, but sometimes a small change is enough to make a big difference which is worth it.

[kasper93]

Needs rebase.