Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On 01/23/2013 01:43 AM, Allan Sandfeld Jensen wrote: On Wednesday 23 January 2013, Balazs Kelemen wrote: On 01/22/2013 05:14 PM, Zoltan Herczeg wrote: 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. You explained the symptom but not the source of the problem. So, do you know _why_ do we have BGRA before the texture upload? If this is a software rendered image buffer, why can't we just use the appropriate format when doing the software rendering? Anybody? Because it is a 32bit buffer of ARGB values. On a little endian CPU like i386, 32bit ARGB is stored bytewise as BGRA. In Qt we always have 32bit ARGB values because that is the internal color format of the Qt renderer (QRgb). In the grand scheme of things it is probably easier up to upload BGRA textures than trying to double the rendering paths of QPainter to support RGBA. A quick little overview of what I am talking about: ARGB format aka RGBA32 (32bit ordered) As 32bit math 8bit big endian 8bit little endian 24-31bit: A 1.byte: A 1.byte B 16-23bit: R 2.byte. R 2.byte G 8-15bit: G3.byte. G 3.byte R 0-7bit: B4.byte. B 4.byte A RGBA format aka RGBA8 (byte-ordered) As byte format32bit big endian 32bit little endian 1.byte: R 24-31bit: R 24-31bit: A 2.byte: G 16-23bit: G 16-23bit: B 3.byte: B 8-15bit: B 8-15bit: G 4.byte: A0-7bit: A0-7bit: R Ofcourse the confusion can be avoided if RGBA8 is only accesed bytewise, and ARGB only 32bit wise, but when uploading to textures or otherwise serializing it we need to deal with the mess. Thanks, that was useful to me. I did not know that the internal format is byte order agnostic. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Monday 21 January 2013, Benjamin Poulain wrote: On Mon, Jan 21, 2013 at 7:00 AM, Zoltan Herczeg zherc...@webkit.org wrote: In WebKit both RGBA and BGRA formats are used for different purposes and different platforms in WebKit. Do we have a policy which one we prefer? It would be nice to reduce conversions between them in the future as it seems costly on embedded systems. The Web APIs use RGBA (E.g. http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#canvas-pixel-array buffer ) Using that internally will prevent conversion at the boundaries JS-WebCore. Internally, each port should be able to use any format. On some embedded systems, it can be advantageous to use 24 bits colors (or even 16 bits sometimes). Where in WebKit do you experience problems with color conversion? Well, for one thing. The Color class and RGBA32 type are encoded as ARGB, not as RGBA which is needed for JavaScript. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
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
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
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
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Tuesday 22 January 2013, Zoltan Herczeg wrote: 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. BGRA is byte order or 32bit ARGB on a little endian machine. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
Couldn't you just swizzle the value in whatever shader you use? Or you could use EXT_texture_format_BGRA or APPLE_texture_format_BGRA. Also, an optimized BGRA-RGBA conversion is about the same cost as a memcpy, so if you have any memcpys you need to do you could possibly replace one with the conversion. On Tue, Jan 22, 2013 at 8:14 AM, Zoltan Herczeg zherc...@webkit.org wrote: 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
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Tuesday 22 January 2013, John Bauman wrote: Couldn't you just swizzle the value in whatever shader you use? Or you could use EXT_texture_format_BGRA or APPLE_texture_format_BGRA. Also, an optimized BGRA-RGBA conversion is about the same cost as a memcpy, so if you have any memcpys you need to do you could possibly replace one with the conversion. memcpy is heavily optimized for different architectures and even subarchitectures. Unless you take the time to write several architecture specific BGRA-RGBA conversions it will never be as fast as memcpy. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Tue, Jan 22, 2013 at 12:39 PM, Allan Sandfeld Jensen k...@carewolf.comwrote: memcpy is heavily optimized for different architectures and even subarchitectures. Unless you take the time to write several architecture specific BGRA-RGBA conversions it will never be as fast as memcpy. This is actually very little work. To summarize, you can: -change the color format of your rasterizer -use extensions for the texture format -use the fragment shader to convert the colors -write an optimized conversion on the CPU, use it when you copy over the data between processes What you take really depends on what is available on your particular platform/port. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On 01/22/2013 05:14 PM, Zoltan Herczeg wrote: 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. You explained the symptom but not the source of the problem. So, do you know _why_ do we have BGRA before the texture upload? If this is a software rendered image buffer, why can't we just use the appropriate format when doing the software rendering? Anybody? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Wednesday 23 January 2013, Balazs Kelemen wrote: On 01/22/2013 05:14 PM, Zoltan Herczeg wrote: 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. You explained the symptom but not the source of the problem. So, do you know _why_ do we have BGRA before the texture upload? If this is a software rendered image buffer, why can't we just use the appropriate format when doing the software rendering? Anybody? Because it is a 32bit buffer of ARGB values. On a little endian CPU like i386, 32bit ARGB is stored bytewise as BGRA. In Qt we always have 32bit ARGB values because that is the internal color format of the Qt renderer (QRgb). In the grand scheme of things it is probably easier up to upload BGRA textures than trying to double the rendering paths of QPainter to support RGBA. A quick little overview of what I am talking about: ARGB format aka RGBA32 (32bit ordered) As 32bit math 8bit big endian 8bit little endian 24-31bit: A 1.byte: A 1.byte B 16-23bit: R 2.byte. R 2.byte G 8-15bit: G 3.byte. G 3.byte R 0-7bit: B 4.byte. B 4.byte A RGBA format aka RGBA8 (byte-ordered) As byte format32bit big endian 32bit little endian 1.byte: R 24-31bit: R 24-31bit: A 2.byte: G 16-23bit: G 16-23bit: B 3.byte: B 8-15bit: B 8-15bit: G 4.byte: A0-7bit: A0-7bit: R Ofcourse the confusion can be avoided if RGBA8 is only accesed bytewise, and ARGB only 32bit wise, but when uploading to textures or otherwise serializing it we need to deal with the mess. Best regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] RGBA8 and BGRA8 formats in WebKit
Hi, In WebKit both RGBA and BGRA formats are used for different purposes and different platforms in WebKit. Do we have a policy which one we prefer? It would be nice to reduce conversions between them in the future as it seems costly on embedded systems. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On Mon, Jan 21, 2013 at 7:00 AM, Zoltan Herczeg zherc...@webkit.org wrote: In WebKit both RGBA and BGRA formats are used for different purposes and different platforms in WebKit. Do we have a policy which one we prefer? It would be nice to reduce conversions between them in the future as it seems costly on embedded systems. The Web APIs use RGBA (E.g. http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#canvas-pixel-arraybuffer ) Using that internally will prevent conversion at the boundaries JS-WebCore. Internally, each port should be able to use any format. On some embedded systems, it can be advantageous to use 24 bits colors (or even 16 bits sometimes). Where in WebKit do you experience problems with color conversion? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
