RESOLVED WONTFIX 119634
[CSS Shapes] Refactor ImageExtractor et al
https://bugs.webkit.org/show_bug.cgi?id=119634
Summary [CSS Shapes] Refactor ImageExtractor et al
Hans Muller
Reported 2013-08-09 11:55:47 PDT
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.
Attachments
Hans Muller
Comment 1 2013-08-12 08:16:19 PDT
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.
Hans Muller
Comment 2 2013-09-05 11:20:29 PDT
We decided to render images instead of depending on ImageExtractor. See https://bugs.webkit.org/show_bug.cgi?id=116643
Note You need to log in before you can comment on or make changes to this bug.