GraphicsContext3D necessarily contains comprehensive image format conversion code in order to support all of the conversions that might be needed during texture uploading. Currently each format conversion is expressed as a function handling a single pixel, and these functions are passed as template parameters so they can be inlined. Unfortunately, this is causing excessive code bloat. In http://crbug.com/78976 thakis suggests making the conversion functions do their work line-by-line and passing them as function pointers instead of template parameters to reduce the code size.
Created attachment 90430 [details] Patch
LGTM.
Comment on attachment 90430 [details] Patch Nifty. What's the before/after size of GraphicsContext3D.o ?
jamesr: See ChangeLog
Committed r84441: <http://trac.webkit.org/changeset/84441>
(In reply to comment #4) > jamesr: See ChangeLog Oh. I can reads good
Comment on attachment 90430 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=90430&action=review > Source/WebCore/platform/graphics/GraphicsContext3D.cpp:373 > + destination[3] = convertColor16LittleTo8(source[3]); Not really related to this work, but if performance is a consideration, doing these conversions an int at a time (or least, using an int pointer for the destination doing a single store) is often much faster than doing char-by-char. SSE2+ would even better would be even better (but more work).
On the chrome bug I suggested jitting up the right conversion function, which is probably best wrt performance. But if anything needs to be color converted on the cpu on every frame, things won't be very fast anyhow.
Possibly related: http://code.google.com/p/chromium/issues/detail?id=91208#c7 As I explain there, I disagree with unstripped object file size as a metric for code bloat. Here, using `nm` tells me that the code generated by these templates is just 25k.