Thanks for testing and detailed report

In normal shooting modes, a few rows in the bottom are dynamic garbage but in normal video mode the live view fills the entire gui window with correct data. In stitch mode, just a small top left area is active, but looks good (with rest of the live view showing previous image). In other video modes only left side of screen is updated and aspect is incorrect.
Much of this is due to not having the added functions that get the real dimensions of the viewport. You can see some of these commented in the a540 code in my branch. You can probably find most of these in the old chdkcam code for your camera, although the function names have changed. However, if you use them for the regular frame buffer dimensions used elsewhere in chdk they may have side effects, which is why they are currently commented in my a540 code. In reality, we should use these for md, histogram etc, because otherwise these will be influenced by the garbage areas.
The video modes are odd on these older cameras, some changes in the framebuffer specs will be required to support this.
Overlay seems to work fine as well. I suppose Canon's menus are not even supposed to be shown (not that I care for them, really)?
If you have overlay enabled, it should show exactly what is on the camera screen. However, if you don't have vid_get_bitmap_active_buffer then you will sometimes see an old version of the bitmap.
The palette will only be correct if *vid_get_bitmap_active_palette() and related functions are implmented. However, the code currently falls back to using a hard coded version of the a540 palette, which is probably pretty close on your camera. Canon menus change the palette though, so they will be wrong.
When live view is enabled, camera is slow to respond to commands from the UI buttons (several seconds for commands to get through) unless target fps is reduced to 4 or lower. That 4.9 fps in the attached screenshots is
What sort of system is this on ? On my laptop (dual core athlon 64 @1.8ghz) it starts to have trouble around 10fps with a540. On linux I've found that it starts acting badly if the total time for the frame (frame ms + xfer ms) approaches the time required to make the target frame rate (1000/fps). I should probably make it start dropping frames when this happens. Actually the whole scheduling is pretty hokey...
D10 does significantly higher frame rates on my cam, because the xfer time is much lower. (20-3ms for a full frame vs 90ms on a540). Oddly, xfer times on my windows box are quite a bit lower with the a540. I also noticed that they are higher in rec mode vs. play. I assume this is because the camera CPU is busier, since the data is the same size.
There's room for improvement in the performance if the drawing part, I'm not going to worry too much about that until we have the functionality sorted out.