Dear All, I have been doing some measurements of the relative speed of hardware-accelerated and software rectangle fills. It seems that on my hardware, doing the fill in software is faster when the rectangle has an area of <= 16 pixels or so.
Here are the full results. The "size", below, is the edge-length of a square. In each case I filled the square 1 million times. The run-times (in seconds) include the program startup time, which is about 1 second. size --dfb:hardware --dfb:no-hardware 1 6.04 4.84 2 5.96 4.94 4 6.03 5.74 8 6.02 8.28 16 6.10 17.63 32 6.02 56.31 64 5.98 128 14.34 So all the way up to a 64x64 square, the graphics hardware is fast enough that it runs faster than the processor. For squares <= 4x4, the software fill loop is faster than the overhead of passing another fill command to the graphics hardware. One thing that I haven't tested is the FillRectangles feature. Does anyone know how it would compare? I imagine that you would see similar results for the other accelerated operations, e.g. blits. In my application, I have quite a lot of small rectangles in some situations: I have a zoom feature, and when you zoom a long way out the screen contains many rectangles that are actually single points. So I could probably make an improvement if this case were optimised. (Not as much of an improvement as I was hoping when I decided to do these measurements unfortunately.) So, is there any way for me to disable hardware acceleration for a particular operation? I was looking at dfb_gfxcard_drawrectangle() in src/core/gfxcard.c, at it seems that it already has logic to fall back to the software implementation in various circumstances. So this could be extended with a check for small dimensions? One thing that concerns me is whether the order of operations is preserved when some things are done by the graphics hardware and some in software. BTW my hardware is VIA unichrome with a 533 MHz processor, so many of you with GHz processors will see better performance from the software operations. Any thoughts anyone? Phil. _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
