The front buffer is probably locked while the compression routine needs it. That'd make the buffer flip block until it's done, which would also block rendering from starting in the backbuffer. The locking may only happen long enough to copy the framebuffer into another memory space if that's faster than compressing it directly. Either one should be much faster than what the screen needs to display it, so the impact here is a lot lower than being vblank locked.
If they're okay with a similar kind of tearing on the WiiU display they could just lock the framebuffer while it copies single macro-blocks or macro-block rows, which would be a negligible amount of time.
With all of Wii's additional memory it shouldn't be a problem to triple buffer, so long as the latency is acceptable..
). I also don't know how you can tell if the video stream is shrunk before broadcast or in the Wuublet. It makes far more sense to do that in the console and save compression time and wireless BW. I think the real meaning here is that the 720p is downscaled to the Wuublet screen and not rendered at native Wuublet resolution.
