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@videotron.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:
- 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.
- 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