The way it works is, anytime a VERA register is updated which would change what's on the screen, the emulator will partially render the current scanline with the old VERA state based on how many pixels would've made it to the display already, then update the VERA state so when the scanline is rendered the rest of the way, it reflects the changed state.
The way it does a partial render is, it renders a full scanline first, then copies the relevant pixels into the line buffer which eventually gets painted to the window.
The problem is, when you use MACPTR to write 10240 bytes to the VERA's data port, the emulator will end up rendering 10240 full scanlines in a vain attempt to try to support any raster-effects it might cause, but MACPTR in the emulator is instant, so 10240 scanlines get rendered and zero pixels actually get used.
I think this is what's causing the emulator to lag so much on this program, but the way you'd improve this would probably require an overhaul of the rendering code so that the VERA's state is only actually looked at when the next pixel of the scanline needs to be output, versus trying to pre-empt it by rendering a full scanline and only sometimes copying pixels from it. I've written a software rendering pipeline like this before, so I can offer some suggestions if needed.
EDIT: I'm pretty sure this is what it is, so I posted a thread about it in the bug report forum.
