Bug 59029 – Reduce size of GraphicsContext3D's compiled code

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Kenneth Russell]

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.

[Kenneth Russell]

Created attachment 90430 [details]
Patch

[Zhenyao Mo]

LGTM.

[James Robinson]

Comment on attachment 90430 [details]
Patch

Nifty.  What's the before/after size of GraphicsContext3D.o ?

[Nico Weber]

jamesr: See ChangeLog

[Kenneth Russell]

Committed r84441: <http://trac.webkit.org/changeset/84441>

[James Robinson]

(In reply to comment #4)
> jamesr: See ChangeLog

Oh. I can reads good

[Stephen White]

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).

[Nico Weber]

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.

[Benoit Jacob]

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.