[PATCH 3/3] winex11: Use TINN algorithm to speed up colour lookups. (try 2)

Vitaly Budovski vbudovski at gmail.com
Tue May 8 01:00:57 CDT 2007


Jesse Allen wrote:
> On 5/7/07, Duane Clark <fpga at pacbell.net> wrote:
>> Dmitry Timoshkov wrote:
>> > "Vitaly Budovski" <vbudovski at gmail.com> wrote:
>> >
>> >>> Now that you got rid of sqrt calls usage of float numbers internally
>> >>> doesn't look justified (to me) anymore.
>> >>>
>> >> Only because in this instance it is used with integer data. It 
>> doesn't
>> >> need to be limited to just integer values. Besides, what would be 
>> gained
>> >> by changing it to integers as you suggest?
>> >
>> > What would be gained is an additional speed. Since this code is 
>> supposed
>> > to be used to handle palette/color data there is no need to use 
>> floats at
>> > all.
>>
>> While I cannot vouch for the accuracy, this might be of interest:
>> http://lua-users.org/wiki/FloatingPoint
>>
>>
>
> Vitaly,
>
> I think I recommend using just integers, and make this private for
> DIBs. Speed is nice for what we can use it for. If someone later needs
> the float use, then we can create a separate float version and
> included where-ever it's used. There is nothing wrong with having two
> versions when each is justified. If you can get your code accepted
> I'll probably move it over to the DIB engine eventually. If the
> wined3d people want to use it, I could make it available somehow?
>
> Jesse
>

Both floats and integers have their share of problems. Since the square
root operation has been removed, we are dealing with much larger
numbers, potentially larger than can fit into unsigned int without
looping back around. This is why I think keeping distances as floats is
a good idea, since they can represent a much larger range of values. As
I mentioned earlier, there is no noticeable performance difference
between using floats and integers (cheap operations +-*) for the
distances so I really don't see the reason for all the resistance.

As for making this private for dibs, are you suggesting that I move the
algorithm into the winex11 directory? I'm certain it could be useful in
other areas too. There is a nearest colour function in gdi32 also, so
once this patch gets accepted I will probably make use of it there too.
Stefan also mentioned a possible use for the algorithm in wined3d.




More information about the wine-devel mailing list