[webkit-dev] RGBA8 and BGRA8 formats in WebKit

noam.rosenthal at nokia.com noam.rosenthal at nokia.com
Tue Jan 22 08:37:40 PST 2013


I would say that the right way to go about improving pixel transfer (which is what you're trying to do, I believe...) is with OS-provided graphics surfaces;

On embedded systems those are usually provided and there are of course solutions for windows and Mac.
When using graphics surfaces, you don't need to swizzle the bits; The OS manages that for you at a lower level. Problem with graphics surfaces is that their characteristics are very platform dependent, and they have delicate memory, performance and security concerns. However, I would explore how we could use graphics surfaces better (e.g. decode images directly into a graphics surface, if the platform allows that), rather than try to fix this on the pixel format level.

If anyone has had experience with doing this, e.g. with IOSurface on Mac, your feedback is welcome...

Noam
________________________________________
From: webkit-dev-bounces at lists.webkit.org [webkit-dev-bounces at lists.webkit.org] on behalf of ext Zoltan Herczeg [zherczeg at webkit.org]
Sent: Tuesday, January 22, 2013 5:14 PM
To: webkit-dev at lists.webkit.org
Subject: Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit

>> Where in WebKit do you experience problems with color conversion?

As for me WebKit2 transmits BGRA images, which needs to be converted to
RGBA before it is uploaded to a texture on GLES 2.0. These conversions
seems computation heavy for certain animations, and I was wondered whether
do we really need to use BGRA here. It would be nice to invent something
to avoid that.

Regards,
Zoltan


_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


More information about the webkit-dev mailing list