With XenForo 1.1, it's now possible to (optionally) define individual smilies from a sprite image. This video shows you just how easy it is to use the system.
Depending on how its done, a modification couldn't you override the settings via an extra.css call? So if you use the same set with exact dimensions on all, just change the CSS variable to be the style specific sprite sheet?Doesn't look like smilies are per-style still?
At least it looks like it'll be a lot easier to multiple smilies now. One image instead of multiple, and just specifying the appropriate dimensions.
That was a thought that crossed my mind as well... maybe an optional thing?Kier: I notice you put styles/ etc. in there. Can a @imagepath be used within the field, or must it always be absolute (if a style property could be used), Onimua's issue would be solved I think?
Optional as it replaces it if its there and goes with what is placed there if its not? Isn't that how style properties work?That was a thought that crossed my mind as well... maybe an optional thing?
That's true, but reducing the smilies to 8 bit depth rather than 24 results in a sprite image that is just 8,225 bytes, rather than the 24 bit version, which is more than three times the size, at 29,048 bytes.I thought it may just have been my eyes but the smilies in the spritesheet (around the edges especially) Are lacking in quality with regards to their smoothness. I'm guessing that is because it's been saved out in .png8 and the smilies use more than the 256 colour range png-8 is limited to.
With regard to the question of efficiency, I'd say that if you have a group of smilies that are commonly used, they are good candidates for a sprite. If you have a smiley that is only used in a small number of posts, and is therefore not commonly requested by browsers, it's probably a good idea to exclude that from a sprite and have it load separately on demand.
You can still have 8 bit depth & alpha transparency though can't you? Of the PNGs I've used & made, I've always done 24 bit and alpha.That's true, but reducing the smilies to 8 bit depth rather than 24 results in a sprite image that is just 8,225 bytes, rather than the 24 bit version, which is more than three times the size, at 29,048 bytes.
That's true, but reducing the smilies to 8 bit depth rather than 24 results in a sprite image that is just 8,225 bytes, rather than the 24 bit version, which is more than three times the size, at 29,048 bytes.
On balance, I think that's a good trade-off, and I doubt that anyone except the smilies' creator would really notice the difference
View attachment 18969 View attachment 18970
Regarding the extended smiley pack, my preference would actually be to distribute two separate smilie sprites, one for all the common smilies, as used now, and a second one for the extended collection. Let's chat later to discuss it furtherI checked the file sizes and totally agree in that case it's definitely the logical choice. It's just that I notice it now that i mentioned it. My concern is with an extended pack in the pipeline, on the same sheet i think for quality purposes you'll be struggling to retain quality with the additional colour range. I'm going to test that out in a moment and check to see if the quality is drastically reduced with the extended ones added.
We use essential cookies to make this site work, and optional cookies to enhance your experience.