Bug 119634
| Summary: | [CSS Shapes] Refactor ImageExtractor et al | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Hans Muller <giles_joplin> |
| Component: | WebGL | Assignee: | Hans Muller <giles_joplin> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 116643 | ||
Hans Muller
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Hans Muller
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
We decided to render images instead of depending on ImageExtractor. See https://bugs.webkit.org/show_bug.cgi?id=116643