Hi Alex
The small fill are calling same fill code as fill does
I have just improve the fill rate for 16bpp
here is my test reslut
vmware 1024x768x16bpp
Before
betwin 10200 - 10300 fill/sec
betwin 298000 - 299000 small fill/sec
after my lates commit
betwin 11200 - 11300 fill/sec
betwin 343000 - 344000 small fill/sec
vline and hline are already max optimize in 16bpp
But line are not yet optimize.
But I will working on that later today
But rember I have build this with oarch=pentium2 DBG=0
Quoting Alex Ionescu <ionucu(a)videotron.ca>ca>:
Hi all,
Here are the latest performance numbers of ReactOS.
All tests done on 800x600x24, except the last one (QEMU + Cirrus
Driver) which was done on 16bpp. It does not skew the numbers too much,
but it's possible the weird result in the "Lines" test is because our
24bpp path is optimized but not the 16bpp one. I will have 16bpp
numbers tomorrow. QEMU B refers to Before optimizations, A refers to
after optimizations. All these tests are done with DBG = 1, so
comparing with XP is slightly unfair right now because our code is even
faster. However, some things are clear:
1) We have greatly improved our fill speed on VBE, as well as
H.Lines...but the V.Lines and Line code has not been changed.
2) We beat XP on all the tests except the Lines and V.Lines/Small Fill
tests (depending if VBE or Hardware Accel (HW) is used)
Therfore, I think that we should stop over-optimizing the Fill Code now
and focus on Small Fill, V.Line and Lines. I think the issue with Small
Fill is that it's handled in C, while Big Fill has the ASM code. As for
Lines, I don't know what it could be... I don't think that code was
touched much.
Best regards,
Alex Ionescu