wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)

[Victor]

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).

-- 
Виктор Ерёмин (ErV2005 at rambler.ru)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080730/cc3a9a99/attachment.pgp