Unfortunately, some of gfx operations with LUT8 formats are woking very slow. The DirectFB's software fallbacks first decode picture into RGB, then convert picture and encode new picture into LUT8 again. The last operation could be very very slow. I think, if your hardware does not support work with LUT8 you can do nothing !
Use others formats of picture instead. For example, I use RGB332 when I need one byte per pixel. 2008/9/1, Garbox <[EMAIL PROTECTED]>: > > Hi, > > I'm working with the directfb 1.1.1 on the MIPS embedded processor. > The problem I am facing with is too slow StretchBlit-ing of 8bitCLUT > surface. If StretchBliting is done with 16bit or 32 color format surface, > operation happens without delay. But, if it's done with 8bitCLUT, procedure > lasts several seconds. > According to the experience, could someone tell me if it is a consequence > of our directfb porting and driver implementation or it is a normal behavior > of StretchBlit-ing with 8bitCLUT due to the duration of the color mapping in > the color lookup table. > > Garbox > _______________________________________________ > directfb-users mailing list > directfb-users@directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users > > -- Best Regards Nikita Egorov [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
