[Webkit-unassigned] [Bug 86515] New: Incorporate Mozilla's improved texture format conversion code

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=86515

           Summary: Incorporate Mozilla's improved texture format
                    conversion code
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebGL
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: kbr at google.com
                CC: senorblanco at chromium.org, jamesr at chromium.org,
                    zmo at google.com, gman at google.com, jbauman at chromium.org
        Depends on: 85942


Mozilla has recently re-worked the code which converts texture data among formats during the upload process to WebGL. From an email from Benoit Jacob:

===
Here is a changeset (currently only on mozilla-inbound) that brings this code size down to 17k on x86-64 (as measured with nm -S on linux). Our previous version, which was already quite careful, was 44k. This is using the 'fully templatized' approach i.e. a separate conversion loop is compiled for each case, traversing the bitmaps only once, with all the texel conversion functions inlined into it.

Changeset:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f87dbd4d39c

The key was to avoid compiling paths that are never called, the code for this is there:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f87dbd4d39c#l4.82
===

It would be ideal to switch WebKit to use this improved code. Among other things, it can avoid a pixel copy in some situations and use a memcpy-optimized loop in more situations than the current code.

However, after analysis, a couple of issues would need to be resolved. The first is that WebKit currently supports many more source formats than the final code Mozilla settled on; compare SourceDataFormat in GraphicsContext3D.h to WebGLTexelFormat in the patch's WebGLContext.h. The major difference is support for 16-bit-per-channel, big-endian and little-endian formats, which only arise in the Core Graphics code path and only in limited situations. The increased number of source formats would probably significantly increase the code size. Since it seems undesirable to have features that are only supported in the Mac port, such images could be converted to 8 bits per channel in the CG code path, before handing the bits to the cross-platform repacking code.

Additionally, the current structure of the WebKit code always packs the Image or ImageData into a Vector<uint8_t> as its first step, preventing some of the key short-circuits in Mozilla's code from taking effect. To fix this, classes which provide scoped access ("lock"/"unlock") to the data in Image or ImageData objects need to be added to GraphicsContext3D; these would be implemented with port-specific code.

Because of the complexity in integrating this code, Bug 85942, which addresses some issues Mozilla found during development of the above patch, has been fixed separately.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.