On Sat, May 8, 2010 at 2:02 PM, Ros Arm <ros.arm@reactos.org> wrote:
Hello,

This is the second time that work that someone on the ARM Team has worked on has been mostly reverted without any communication with us, and incorrect changes have been added to parts of our work.

The Eng function worked on even clearly stated comments such as "Compressed surfaces don't have scanlines!", yet this new patch restores the old incorrect functionality.

lDelta cannot be anything but != 0 for compressed data such as RLE or JPG/PNG! And creating the DIB should not decompress the bits.

Please read http://www.tech-archive.net/Archive/Development/microsoft.public.development.device.drivers/2009-05/msg00165.html for example.

I do not understand how you can believe that "RLE" has a scan-line. I am not a graphics expert by no means, but even I understand this fact: by definition scan-lines in an RLE are dynamic, and a scan-line offset table contains information about that.

You do not have to take my word for it, as a simple driver test case will also show that Windows does not decompress RLE data or set lDelta to any other value than 0 with an RLE bitmap. You can find more information on RLE at http://www.fileformat.info/mirror/egff/ch09_03.htm.

If you are wondering why there have not been any commits coming lately, recent actions such as these as the cause.

-r


I've not seen any ARM ninjas on the mailing list recently either. Where is the communication?