For extended and deep colors, we'll need to update Color.h. We'll need a reference to a ColorSpace and probably floating point component values.
<rdar://problem/27667095>
8/2/16, 4:17 PM Dean Jackson: Doing some allocation tracking it seems an average page (macrumors daringfireball) has on the order of 3000 - 6000 colors. 8/2/16, 4:19 PM Dean Jackson: Lea's amazing http://leaverou.github.io/conic-gradient/ got to about 8200 live color instances. 8/2/16, 4:25 PM Dean Jackson: Although, that number would probably be smaller if we implemented conic-gradient :) The single page HTML5 got to about 300,000 colors at its highest point, so an extra 64bit pointer would be about 2.25 Mb of extra memory (double what the current Color is). 8/3/16, 11:14 AM Dean Jackson: If we start counting unique colors.... daringfireball.net 22 html5 spec 106 (out of 350k creations) macrumors 76 apple.com/iphone 26 BBC 68 etc 8/3/16, 1:18 PM Dean Jackson: With discussion from Sam: Current - 64 bits (32 for inline color, 1 bit for validity) - Inline access Double Size - 128 bits (32 for inline color, 1 bit for validity, 64 bits for pointer to extended data) - Direct access Con: - Double the size ~2MB extra on HTML spec test Atomic Color (the color of tomorrow) - 64 bits (64 bits for pointer to uniqued color) - Indirect access Con: - Indirect access might be a perf hit Tagged pointer - 64 bits (same as current, except you have a bit which tells you if this is a pointer to the extended data) - Direct access after branch Con: - Adds a branch to all color access - Might not work with current tools 8/3/16, 1:18 PM Dean Jackson:
1. Color will get rid of m_isValid and m_color, and use RefPtr<ColorImpl>. 2. isValid() becomes m_colorImpl != nullptr 3. ColorImpl will start with just the RGBA struct (add space and deeper colors later) 4. Table will live in Color.cpp
Isn't this mostly done?