119634 2013-08-09 11:55:47 -0700 [CSS Shapes] Refactor ImageExtractor et al 2013-09-05 11:20:29 -0700 1 1 1 Unclassified WebKit WebGL 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 116643 1 giles_joplin giles_joplin oldest_to_newest 915899 0 giles_joplin 2013-08-09 11:55:47 -0700 The ImageExtractor class, its packImageData() helper function, and related definitions are currently embedded in the GraphicsContext3D class. The proposed Shape from Image patch, https://bugs.webkit.org/show_bug.cgi?id=116643, depends on these classes but not on anything else, not on anything 3D graphics related. The reviewer for 116643 has asked that ImageExtractor et al be refactored out of the Graphics3D class. 916275 1 giles_joplin 2013-08-12 08:16:19 -0700 Separating ImageExtractor et al from GraphicsContext3D would be a big job. Bigger than I'd thought. For example: - GraphicsContext3D.h defines a huge grab-bag of constants, some of which are used by the pixel reformatting code. - GraphicsContext3D.cpp includes two HUGE blocks of file-local definitions in anonymous namespaces. Most of those definitions are used by the image extraction code but probably not all of them. - The ImageExtractor class depends a native method called extractImage() of which there are at least 7. All of the native code would have to be rearranged. It might be simpler to render the image instead, despite the extra (ephemeral) memory cost of doing so. I'd suggested doing as much back in May. See the email to Alex and Dirk, subject "Image Processing", May 22. Here's how it might work: Use ImageBuffer::create() to create an ImageBuffer of the right size. Draw the Image* with the GraphicsContext returned by imageBuffer->context(). Use ImageBuffer::getUnmultipliedImageData() to extract the RGBA pixels data. There are loads of examples of roughly this kind of thing. 925137 2 giles_joplin 2013-09-05 11:20:29 -0700 We decided to render images instead of depending on ImageExtractor. See https://bugs.webkit.org/show_bug.cgi?id=116643