Ang isang custom head ay nag-iimbak ng URL na nakabalot sa base64 JSON, hindi isang imahe
Naglalaman ang profile component ng base64 ng {textures:{SKIN:{url:…}}}. Ito ang dahilan kung bakit permanente ang hitsura ng ulo sa oras na ginawa ito, at kung bakit maaaring magkaroon ng sampu-sampung libong entry ang database.
Ang isang custom player head ay hindi naglalaman ng larawan. Naglalaman ito ng texture hash, na nakabalot sa JSON, nakabalot sa base64, na nasa loob ng profile component ng aytem.
Ang mga layer
Mula sa isang hash, binuo ang command nang ganito:
1. hash e3b0c44298fc1c149afbf4c8996fb924…
2. JSON {"textures":{"SKIN":{"url":"http://textures.minecraft.net/texture/<hash>"}}}
3. base64 eyJ0ZXh0dXJlcyI6eyJTS0lOIjp7InVybCI6…
4. component /give @p player_head[profile={properties:[{name:"textures",value:"<base64>"}]}]Apat na layer upang sabihing "kamukha ng imaheng iyon ang ulong ito". Ang property ay laging pinangalanang textures, and the value is always the base64 of that JSON shape.
Dalawang bagay ang direktang sumusunod:
Ang ulo ay isang snapshot, hindi link sa isang tao. Ang URL ay tumuturo sa isang hindi nababagong texture file, hindi sa isang account. Kung ano man ang katumbas ng hash noong ginawa ang ulo ay iyon palagi ang ipapakita nito.
Napakaliit ng data. Ang isang head entry ay binubuo ng pangalan, hash at ilang tag — walang image bytes. Ito ang dahilan kung bakit kayang maglaman ang isang katalogo ng sampu-sampung libong ulo bilang payak na static JSON at mabilis pa ring mag-load.
Bakit naglo-load ayon sa kategorya ang katalogo
Ang database dito ay ang CC0 head collection ni TheSilentPro, at kinukuha ito nang paisa-isang kategorya sa halip na sabay-sabay. Naglilista ang isang index ng mga kategorya at bilang ng mga ito; ang pagpili sa isa ay kukuha lamang sa file na iyon.
Hindi iyon katamaran sa engineering, ito lamang ang paraang epektibo sa laking ito. Ang buong koleksyon bilang iisang JSON ay magiging malaking download para sa isang taong tatlong ulo lamang ang gusto mula sa isang kategorya.
Ang 300-item render cap ay limitasyon ng DOM, hindi limitasyon ng paghahanap
Ang mga resulta ay ipinapakita nang hindi hihigit sa 300 sa bawat pagkakataon. Tumatakbo pa rin ang paghahanap sa lahat ng nasa na-load na kategorya — nalalapat ang cap sa kung ilan ang nagiging mga DOM node, hindi sa kung ilan ang sinusuri.
Mahalaga ang pagkakaibang ito kapag sinabi ng paghahanap na ipinapakita nito ang unang 300: natagpuan ang mga nawawalang entry at pinipigilan lamang sa page, hindi ibinukod sa query. Ang pagpapakitid ng paghahanap ay naglalagay sa mga ito sa saklaw sa halip na maghanap nang mas mabigat.
Ang pagpapakita ng sampu-sampung libong elemento nang sabay-sabay ang layuning pigilan ng cap, at ito ay isang tunay na limitasyon sa halip na isang depensibong numerong pabilog — ang ganoong kalaking grid ay hindi na mai-scroll bago pa man ito tuluyang hindi ma-render.
Walang anuman dito ang nag-a-upload
Ang data ng ulo ay same-origin static JSON. Ang tanging third-party request ay ang <img> preview from mc-heads.net, which resolves a hash into a picture for display. The /give command is assembled locally from the hash, so the command works whether or not that preview loaded.