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. 
This will require several nearly identical read functions, or callbacks which 
means either code duplication or slowdown within Blt function, which isn't 
good idia, IMHO.

> That's of course only if the data is 
> supposed to be swapped on big-endian; if you assume that the data is
> always little-endian then you read byte by byte and rebuild DWORDs from
> that. Either way you don't access a DWORD mask as an array of bytes.
I"ve resubmitted patch and removed accessing DWORDs as bytes where it was 
possible (it was possible only in one place, actually). Accessing DWORD mask 
as array of bytes is required by algorithm. Accessing everything as DWORD is 
not possible, because, for example, accessing last pixel of r8g8b8 as DWORD 
will cause segfault, unless there is one additional byte available due to the 
surface alignment. Making several different functions which will read 1/2/3/4 
bytes seems clumsy/pointless to me.

> You also need to do this in a single pass, it's silly to go through the
> data 5 times, you should handle each pixel completely before moving on
> to the next. 
Conversion process for every channel is identical, and calling several if's 
for every pixel doesn't look like good idea (code duplication/slowdown). 
That's why surface is walked several times. Also, generic per-channel 
functions allows to add support for other formats later.

> You also have to expand types properly, i.e. converting a 
> component from 4-bit to 8-bit isn't just a shift.
In all places where I saw pixel format conversion before, it was _always_ done 
by shifting components (even in MS-DOS vesa-based applications). 
Your assumption that "converting isn't just a shift" requires link to official 
documentation (i.e. proof), where it is clearly stated that during Blt() 
(from which convert_unsigned_pixels is being called) between different 
surface format, ddraw/d3d converts pixel format by means other than simply 
shifting components. I doubt that in real software ddraw implementation blt 
from 565 to 888 is done by completely recalculating components using floating 
point operations.

-- 
Виктор Ерёмин (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/4427424f/attachment.pgp