charliedurrant wrote:What you said about a 'full synchronise' is interesting as esentially it means that the drawing / text code needs to be as quick as possible!
Haha yes! Or the least amount of work to get the same visual effect as possible
Ideally if work is to be submitted it's also nice to get it in big blocks. eg a fill that's 100x100, rather than 10000 1x1 fills. The copy and fill operations when powered by DMA need quite some time to get into their stride. I've geared composite for tiny operations though (think lots of characters of text) and doesn't scale well to large blocks...but that may change soon
I'm going to get cross compiling working on my VM, I've seen posts about remote debugging which may help you as you must be having a hard time working directly on the Pi.
Debugging is easy enough, I could even hook it up to Eclipse on my PC if required. I do it all via gdb and SSH, and have about a dozen putty windows open which delights my girlfriend. Also a USB serial port connected to the GPIO in case I need to debug the kernel!
It's the code build time that is annoying IMO
p.s. I'm currently attempting to teach my children some python and I genuinely believe this is an important area, i.e. making the general UI as responsive as possible with respect to schools etc. Sounds a bit naff....but I do think what you are doing will make a big difference....!
Definitely a worthy thing to do. But you need a good example of good versus bad. My mum always said no to hardware upgrades when I was a growing up but when she saw me playing Doom on xmas day in the tiniest of windows at 2-3 fps that's when she finally got what I was talking about! Waiting for a paint pot to ray trace is quite different to an interactive application...
Anyway, driver update: work has been done on the non-interesting driver stuff for about a week now to,
a) make it easy for people to just do rpi-update and get all the tricky things installed for you (ie the kernel module)
b) make it easy for people to set up the driver - it now supports the experimental floating CPU/GPU memory split so you haven't got to "pick a split" if you want to use my code.
c) provide a framework to accelerate large composition operations...this could pay off big time if I'm lucky.
If I can get some easy wins with (c) then I'd be much happier to release that version than what I had a month ago.
Big thanks to Dom for his work.