Using the PMg shapes is faster and saves a lot of characters.
You'd only need 4 characters, 1 each filled with the colour patterns $00, $55, $AA and $FF, but you could probably get away with two, for example for the sky rock colours.
Writing to one memory byte in the screen's memory in Antic 4 character mode will have the effect of covering a 4*8 pixel area of the display. Therefore 2 writes cover an 8*8 area, 4 covers a 16*8 and 8 covers a 32*8 area.
Alternatively handling this with Player data (i.e. DMA enabled) would require the following:
A double-line mode player of normal, double and quadruple width needs 4 writes to fill the same vertical height.
This can handle a 4*8 area when you set half the pixels in normal width player. So this is 4 times slower.
This can then handle an 8*8 area if you set all the pixels in normal width. So this is twice as slow.
It can handle a 16*8 area when you set all the pixels in double width. So this is works out as the same.
It can also handle a 32*8 area by setting all the pixels in quadruple width. So yes, this would be twice as fast.
A single-line mode player of normal, double and quadruple width needs 8 writes to fill the same vertical height, so:
A 4*8 area setting half the pixels in normal width, this is 8 times slower.
An 8*8 area setting all the pixels in normal width, this is 4 times as slow.
A 16*8 area setting all the pixels in double width, this is twice as slow.
A 32*8 area setting all the pixels in quadruple width, works out as the same.
Of course there is the option of not using PM DMA but then you are responsible for managing the turning on the pixels at the right ypos and off again, the overheads of which I should think are again going to be more or less the same or worse when comparing with the overheads of the DMA. Especially if you consider having to also set various player's xpos over the height of the screen too.
You can cheat a bit with fill on the C64 by using attributes, though they only apply to foreground colours.
You can do the same thing on Atari but have to use the multicolour text mode.
I'd therefore suggest that this method would be a more sensible approach. As far a I can see, only the quad-width players may offer something comparable but would argue here that handling the granularity, i.e. working out if 1..8 pixels need to be set (e.g. when the wall edge gets closer to the edge of a screen) would again be a greater overhead.
This simplistic math may have missed something so I'm more than happy to have it demonstrated where the Player/Missile approach works better for a whole screen. Perhaps two g2f's of a captured screen with an explanation of the fill loops for the solid areas would help?