> [...]
> > This uses an O(n) algoritm but can be implemented
> > with and O(log(n)) algoritm one I think.
> >
> > > 21.52 24.1 1.1 PolyLine
>
> This kind of optimisation, i.e. at the algorithmic level, may be
> useful. Although it's probably not a priority right now.
The comment was about GetNearestColor.
23.82 5240000.0 220000.0 GetNearestColor
But I agree anyway. :-)
> [...]
> > I have slight optimized it as I said above.
> > MoveTo16 now directly calls MoveToEx(32)
> > instead of MoveToEx16. This might make
> > some difference if the difference is
> > this large in the benchmark.
>
> Doesn't this contradict your first point above?
Perhaps. I only saw the difference when I wrote the mail.
I didn't think very much about it.
> This will probably not make a big difference. Look at the
> difference
> between MoveTo and MoveToEx for instance:
> Ratio Win Wine Test
> 11.06 7810000.0 706000.0 MoveTo
> 8.78 6290000.0 716000.0 MoveToEx
>
> In the code MoveTo16 calls MoveToEx16 and does one MAKELONG.
> That's the only difference. MoveToEx seems to do much better than
> MoveTo but that's only because Windows's MoveTo is 24% faster than its
> MoveToEx.
OK.
> If we look at Wine's results we see that there's only a 1%
> difference. So I expect that calling MoveToEx(32) directly
> will gain us
> at most 1% since we skip 1 call but still have to do things like the
> MAKELONG the CONV_POINT32TO16 and other parameter conversions. So it's
> probably not worth it.
Well. I also made some changes to optimize the generated code,
so it might make a little more difference than 1%.
However the important change is DC_GetDCUpdate to DC_GetDCPtr.
