martin@minster.york.ac.uk (03/01/88)
Since no-one else has pointed this out - here goes. As far as I can tell from the literature, by far the best way to do (software) BitBlt (RasterOP, or whatever you want to call it) is to compile (semi-)optimal code on the fly, after analysing the particular BitBlt being done, and jump to it. See below for (so far) the best BitBlt I have seen. I can thoughly recomend the paper too. Now I specifically DO NOT want the overhead of a system call every time I do a BitBlt in order to flush the I-cache/prefetch/etc. SunOS provides such a trap, but fortunately it is possible (with some knowledge of the cache) to manage without, and this is what our local BitBlt does. Martin usenet: ...!mcvax!ukc!minster!martin PS The reference: %T Fast bitblt() with asm() and cpp %A Bart Locanthi %J Proceedings of the EUUG Conference %D September 21-25, 1987 %C Dublin, Ireland %P 243-259 a PPS If anyone knows of a Bitblt which is fast AND smaller or simpler, I would be interested... By the way... $ wc -l bbb/sun/*.c 307 bbb/sun/mem_rop.c 193 bbb/sun/templates.c 500 total $ size bbb/mem_rop.o bbb/mem_rop.o: 1564+1960+0 = 3524b = 0xdc4b
trickey@alice.UUCP (03/04/88)
In article <573153807.18007@minster.york.ac.uk>, martin@SoftEng.UUCP writes: > BitBlt being done, and jump to it. See below for (so far) the best BitBlt > I have seen. I can thoughly recomend the paper too. > The reference: > %T Fast bitblt() with asm() and cpp > %A Bart Locanthi another ref, more story: Hardware/Software Tradeoffs for Bitmap Graphics on the Blit Rob Pike, Bart Locanthi and John Reiser Software - Practice and Experience, Feb 85