How does RBackedupWindow interact with app Menu??

We have never got RBackedUpWindow to behave in any sane way, for the usecase you describe.

I would recommend using your own offscreen bitmap, and draw that one through the normal CWindowGc of your control.

That is the most compatible way to do it, and will always work on any phone.

For the blitting to be as efficient as possible, you should make sure the bitmap has the same displaymode as the screen.

If this really is not enough you could consider useing DSA to track your windows visible region, and blit directly to the screen. (as opposed to telling the wserv through IPC, that it should blit your bitmap to the screen as in above)

DSA can though be tricky to get right though, and could also interfere with other stuff in the phone wanting to use DSA.

I recommend the first solution, and it should be enough for almost all applications.
performance difference is not much compared to DSA as long as you don't rewrite your blitting routines to something faster then what is normally given by CFbsBitGc.
Or if you have a render engine that can draw regions and not only rects, you could also gain some on skipping the copying totally and draw directly too screen.
Though, this has also implications, somtimes (depening on what you draw and how, and how caches are configured) it might be faster to draw to a bitmap and copy to screen, then do draw to screen.

All these above methods does though have one problem in common: Tearing.

If you want to get rid of tearing too, you have no choice but to use CDirectScreenBitmap.
CDirectScreenBitmap is supposed to be used with DSA, though you will notice that the DSB interface isn't really compatible with DSA and regions, just rects..  But as long as you only draw fullscreen or in a rect it is usable. Also, there is issues in getting the framerate over 18fps, without some advanced active object programming...

Good luck