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-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of ext Zoltan Herczeg [zherc...@webkit.org] Sent: Tuesday, January 22, 2013 5:14 PM To: webkit-dev@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
