Firefox/Projects/IconRefactor: Difference between revisions

Firefox/Projects/IconRefactor (view source)

Revision as of 05:36, 28 January 2010

882 bytes added , 28 January 2010

→‎Potential Changes

Faaborg

497

edits

@@ Line 28: / Line 28: @@
 ''Stencil files''
 *These are very large png files that contain every icon for a particular OS or OS theme arranged in a grid, likely with some surrounding explanatory text (perhaps as a separate photoshop layer to reduce the size of the final file).  These large files are created by themers and design firms, and are (possibly) directly checked in.  The Mozilla platform has a stencil file displaying all of the standard icons available to everyone, and each app can provide an additional stencil file for the few extremely specific icons that they provide in addition.
+* File names would likely be [Scope]-[OS]-[OS theme] for example mozilla1-9-2-osx-aqua.png, Firefox4-windows-xp-luna.png
 ''Icon manifest''
 *This maps moz-icon:// urls to a particular a moz-image-region in a the appropriate stencil file.
+*moz-icon URLs should be short and descriptive, but will need to define if they are part of the platform or app specific, so for instance moz-icon://star-16 is available to any app built on the mozilla platform, while moz-icon://firefox/masquerademask-32 is specific to Firefox using the format [optional scope]-[literal name]-[size]-[optional special state]
 ''Performance magic (very much to be determined)''
-There are a lot of ways we could do this, but essentially we take in a stencil file and a manifest file and do something along the lines of:
+*There are a lot of ways we could do this, but essentially we take in a stencil file and a manifest file and do something along the lines of:
-* Prior to check in automatically generate a series of images similar to the current toolbar.png using a second manifest that knows which files are commonly loaded together
+** Prior to check in automatically generate a series of images similar to the current toolbar.png using a second manifest that knows which files are commonly loaded together
-* At build time automatically generate grouped images based on actual metrics of which files are loaded together
+** At build time automatically generate grouped images based on actual metrics of which files are loaded together
-* At run time intelligently cache icons in memory, stream in parts of the stencil file without loading the entire thing, and only access the file once per group of icons that need to be loaded
+** At run time intelligently cache icons in memory, stream in parts of the stencil file without loading the entire thing, and only access the file once per group of icons that need to be loaded
-We could start with one approach and then over time adjust to a more automated approach.  Theoretically returning images to calls with moz-icon
+*We could start with one approach and then over time adjust to a more automated approach.  Theoretically returning images to calls with moz-icon urls could have even better performance than our current approach since we often load the same image (different files) multiple times, and I believe don't cache any common files in memory, but load them over and over again.
+*Having a moz-icon protocol for access is key, all of the future performance enhancements to loading icons build on some form of existing intermediary description of the file
 ''Literal naming''
-*Every moz-icon:// url should use a very literal name of what is actually pictured, so for instance moz-icon://puzzlepiece-32 instead of "extension-32" or moz-icon://star-16 instead of "bookmark-16" (Firefox uses stars for bookmarks, while thunderbird for staring emails, etc).
+*Every moz-icon:// URL should use a very literal name of what is actually pictured, so for instance moz-icon://puzzlepiece-32 instead of "extension-32" or moz-icon://star-16 instead of "bookmark-16" (Firefox uses stars for bookmarks, while thunderbird for staring emails, etc).
 ''about:icons''