On Tuesday 29 July 2008 21:54:36 you wrote:
Obviously not, 1-byte formats should be read as bytes, 2-byte format as WORDs, and 4-byte format as DWORDs.
How it is supposed to be implemented inside pixel conversion loop? As separate per-pixel callbacks for fetching data? Or as switch()? The best way to do this, of course, would be compiling (on the fly) optimized conversion function on the fly from pre-generated parts, but I don't think that WINE is the right place to do stuff like this, especially for functions like this one.
Either way you don't access a DWORD mask as an array of bytes.
No, accessing DWORD masks as array of bytes still will be reasonable. Look at mask_set() and mask_erase() functions. It could be possible to set those values always as DWORDs, but that will cause segfault on last pixel for pixelsize < 4, if surface rows aren't 4-byte aligned. In mask_copy accessing dword as array could be removed (will this be enough to make patch accepted, by the way?), but in mask_set/mask_erase it can't, and j-related macros will be still here.
You also need to do this in a single pass, it's silly to go through the data 5 times,
This would require if/else within pixel procession loop. I don't think that it's good, since for each channel there will be code duplication. Also, the data isn't always walked 5 times. Surface is walked through only if channel exists. If there is only RGB in both surfaces, data is walked only three times, if there is only L in both surfaces, then it's walked once.
You also have to expand types properly,
What exactly do you mean?
i.e. converting a component from 4-bit to 8-bit isn't just a shift.
Are you suggesting convert each shifted source component into float, divide it by source mask, multiply by shifted destination mask, then convert it back to int, preferably with dithering? This certainly wouldn't be fast.
For the sake of robustness it's quite safe to assume that shifted result is close enough. By the way, pixel colors were always converted by shifting them, not by calculating "truly correct" value (assuming that 0xFF in 8bit is equal 1.0 in floating point and is equal to 0xF in 4-bit).