On Sun, 29 Jul 2012, Andrew Flegg wrote: > On 29 July 2012 20:41, Jeffrey Lee <m...@phlamethrower.co.uk> wrote: >> >> Abstractable, yes. Abstractable without impacting performance? Doubtful. >> Remember that I fought long and hard to get ArcEm to run at ARM2 speeds on >> an Iyonix, so I don't really want us to start doing things that will harm >> performance unless we've got a good reason! > > Fair point, the first pass I'd do is to have a single method which > always calls through to Write_Pixels (which might then have special > casing when n = 1). Is the additional method calling overhead the > concern?
Anything that could conceivably make things slower is a concern ;) If you were always calling Write_Pixels, and the number of pixels isn't known at compile time, then Write_Pixels is always going to force the CPU to either branch or loop, which will obviously be slower than how things are now, where the compile can optimise any loops out of Write_Pixels. Of course I haven't actually tried doing the above, so I've got no idea whether it'll be significantly slower or not. > Of course, X/true.c isn't used on the Iyonix (i.e. RISC OS port) is it? X/true.c isn't, but arch/stddisplaydev.c is (which as you've spotted contains the guts of the display code). Cheers, - Jeffrey ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
