Hi,
Ok, I try to find out the root of the problem. I've also made a patch to
speed up the conversion from rgba to rgb in 24bpp.
----- Mail original -----
De: "Carsten Haitzler" <ras...@rasterman.com>
À: "david oboeuf" <david.obo...@aliceadsl.fr>
Cc: "Enlightenment developer list" <enlightenment-devel@lists.sourceforge.net>
Envoyé: Mercredi 25 Juillet 2012 12:07:40
Objet: Re: [E-devel] Patch for endianness conversion
On Tue, 24 Jul 2012 07:31:28 -0400 (EDT) david.obo...@aliceadsl.fr said:
if you can find out why evas is using the wrong format - that'll be useful. i
dont know what fbset output means. :)
> The color format is wrong, but now, I don't know if it's our framebuffer or
> evas the problem. Except for this point, all runs fine (I run Enna on my
> STB). I'm right to make this patch, I will work this afternoon on this
>
> ----- Mail original -----
> De: "Carsten Haitzler" <ras...@rasterman.com>
> À: "david oboeuf" <david.obo...@aliceadsl.fr>
> Cc: "Enlightenment developer list" <enlightenment-devel@lists.sourceforge.net>
> Envoyé: Mardi 24 Juillet 2012 11:39:42
> Objet: Re: [E-devel] Patch for endianness conversion
>
> On Tue, 24 Jul 2012 05:34:06 -0400 (EDT) david.obo...@aliceadsl.fr said:
>
> > Mea Culpa, I haven't see it's already make in evas_common.h with the macros.
> > It's a problem with my platform.
>
> no worries - happy to help out. if evas's color format choosing is wrong -
> please let us know - or ecore-evas. check there. the 24bpp support is almost
> never used so its never tested "in real life".
>
> nb - the converter COULD be faster by handling 4 pixels at once packing them
> into 32bit registers (well just vars - registers will be handled by the
> compiler) and writing out whole ints at a time (read 4 pixels, write 3 ints
> which contain 4 pixels). THEN endianess WOULD matter. :) you'd be right to
> want to patch. :) also if we had mmx/sse asm to do this too.
>
> > Thanks
> >
> > ----- Mail original -----
> > De: "Carsten Haitzler" <ras...@rasterman.com>
> > À: "Enlightenment developer list"
> > <enlightenment-devel@lists.sourceforge.net> Cc: "david oboeuf"
> > <david.obo...@aliceadsl.fr> Envoyé: Mardi 24 Juillet 2012 11:27:50
> > Objet: Re: [E-devel] Patch for endianness conversion
> >
> > On Tue, 24 Jul 2012 05:21:08 -0400 (EDT) david.obo...@aliceadsl.fr said:
> >
> > > I don't think so, the source is 32bit, so we advance 4 bytes (for the
> > > source) and we choose 1 bytes for each color (and write it in the
> > > destination), the endianness make sens when we write from source to
> > > destination.
> >
> > those R_VAL etc. macros handle edianess already - evas's rgb vormat is fixed
> > in memory. per pixel its an int (4 bytes) with MSB being A, LSB being B. if
> > you address it as an int and bitshift u never have to care about endianness.
> > if u access byte by byte you do. the output is byte-based. you swapped the
> > output in your patch and as such there are 2 diferent routines to deal with
> > the 2 orderings for output - RGB or BGR (byte-by-byte order).
> >
> > > here is the RGBA result of fbset:
> > > rgba 8/16,8/8,8/0,0/0
> > >
> > > and evas detect a RGB format
> > >
> > > ----- Mail original -----
> > > De: "Carsten Haitzler" <ras...@rasterman.com>
> > > À: "Enlightenment developer list"
> > > <enlightenment-devel@lists.sourceforge.net> Cc: "david oboeuf"
> > > <david.obo...@aliceadsl.fr> Envoyé: Mardi 24 Juillet 2012 10:27:44
> > > Objet: Re: [E-devel] Patch for endianness conversion
> > >
> > > On Tue, 24 Jul 2012 03:32:25 -0400 (EDT) david.obo...@aliceadsl.fr said:
> > >
> > > > Hi everybody,
> > > >
> > > > I work actually on a set-top-box little endian with a 24-bit depth
> > > > framebuffer (evas version 1.2.1). I noticed there are no conversion
> > > > between little endian and big endian (my color was inverted). I propose
> > > > a patch to handle the endianness for this depth (I test only the
> > > > evas_common_convert_rgba_to_24bpp_rgb_888 fonction).
> > >
> > > hmm this is wrong. as its writing 1 byte at a time and advancing 3 bytes
> > > a time this has nothing to do with endianess. your 24bit framebuffer
> > > (unusual these days) is literally BGR nor RGB. not an endianess matter
> > > (it would be if we were writing int's (32bits) at a time). :) ie uw ant
> > > to be using
> > >
> > > evas_common_convert_rgba_to_24bpp_rgb_888()
> > >
> > > instead of
> > >
> > > evas_common_convert_rgba_to_24bpp_bgr_888()...
> > >
> > > or the other way around - i have no idea which one is being used in your
> > > case
> > > - but something is telling the evas convert subsystem to use the wrong
> > > 24bpp format for your hardware. :)
> > >
> > > --
> > > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Live Security Virtual Conference
> > > Exclusive live event will cover all the ways today's security and
> > > threat landscape has changed and how IT managers can respond. Discussions
> > > will include endpoint security, mobile security and the latest in malware
> > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > > _______________________________________________
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler) ras...@rasterman.com
> >
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
--- evas-1.2.1.orig/src/lib/engines/common/evas_convert_rgb_24.c 2012-05-12 22:47:08.000000000 +0200
+++ evas-1.2.1/src/lib/engines/common/evas_convert_rgb_24.c 2012-07-25 12:19:32.000000000 +0200
@@ -5,8 +5,10 @@
void
evas_common_convert_rgba_to_24bpp_rgb_888(DATA32 *src, DATA8 *dst, int src_jump, int dst_jump, int w, int h, int dith_x __UNUSED__, int dith_y __UNUSED__, DATA8 *pal __UNUSED__)
{
- DATA32 *src_ptr;
+ DATA32 *src_ptr, *dst_ptr2;
+ DATA32 data;
DATA8 *dst_ptr;
+ DATA16 rotate, rotate2;
int x, y;
dst_ptr = (DATA8 *)dst;
@@ -16,11 +18,21 @@
{
for (x = 0; x < w; x++)
{
- dst_ptr[0] = R_VAL(src_ptr);
- dst_ptr[1] = G_VAL(src_ptr);
- dst_ptr[2] = B_VAL(src_ptr);
+ data = *src_ptr;
+ dst_ptr2 = (DATA32 *)dst_ptr;
+#ifndef WORDS_BIGENDIAN
+ rotate = (DATA16)data;
+ rotate2 = (DATA16) (data >> 16);
+ rotate = ( (rotate) >> 8) | ( (rotate) << (sizeof( (rotate) )*CHAR_BIT - 8));
+ rotate2 = ( (rotate2) >> 8) | ( (rotate2) << (sizeof( (rotate2) )*CHAR_BIT - 8));
+ data = (rotate << 16) | rotate2;
+#endif
+ data = (data >> 8) | (data << (sizeof(data)*CHAR_BIT - 8));
+ data = data & 0x00ffffff;
+
+ *dst_ptr2 = data;
+ dst_ptr += 3;
src_ptr++;
- dst_ptr+=3;
}
src_ptr += src_jump;
dst_ptr += (dst_jump * 3);
@@ -64,8 +76,10 @@
void
evas_common_convert_rgba_to_24bpp_bgr_888(DATA32 *src, DATA8 *dst, int src_jump, int dst_jump, int w, int h, int dith_x __UNUSED__, int dith_y __UNUSED__, DATA8 *pal __UNUSED__)
{
- DATA32 *src_ptr;
+ DATA32 *src_ptr, *dst_ptr2;
+ DATA32 data;
DATA8 *dst_ptr;
+ DATA16 rotate, rotate2;
int x, y;
dst_ptr = (DATA8 *)dst;
@@ -75,11 +89,20 @@
{
for (x = 0; x < w; x++)
{
- dst_ptr[2] = R_VAL(src_ptr);
- dst_ptr[1] = G_VAL(src_ptr);
- dst_ptr[0] = B_VAL(src_ptr);
+ data = *src_ptr;
+ dst_ptr2 = (DATA32 *)dst_ptr;
+#ifdef WORDS_BIGENDIAN
+ rotate = (DATA16)data;
+ rotate2 = (DATA16) (data >> 16);
+ rotate = ( (rotate) >> 8) | ( (rotate) << (sizeof( (rotate) )*CHAR_BIT - 8));
+ rotate2 = ( (rotate2) >> 8) | ( (rotate2) << (sizeof( (rotate2) )*CHAR_BIT - 8));
+ data = (rotate << 16) | rotate2;
+#endif
+ data = data & 0x00ffffff;
+
+ *dst_ptr2 = data;
+ dst_ptr += 3;
src_ptr++;
- dst_ptr+=3;
}
src_ptr += src_jump;
dst_ptr += (dst_jump * 3);
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
