Why use direct screen access? Direct screen access doesn't give you access to the pixel data of the screen ( even if the name sounds like that ). I know that there is a "dirty" way for getting direct access to the pixel data of the display but I would not suggest using such an unsafe way because in the next firmware release or on another Series 60 device this might not work correctly. For this reasons and because of the flickering in which direct pixel access would result ( seeing the overdraw of pixels ) you always have to use a back buffer surface.
This brings us to the fact that ALL drawing operations are done onto the back buffer surface ( a CFbsBitmap in our case ). So the direct screen access is NOT involved in all this operations! Just the blit off the backbuffer to the screen could be faster with the direct screen access API. But I think that this one blit can't be that slow and you have more code if you use the direct screen access API and things just get more complicated.
So I can't see the advantages which would justify using the so much recommended direct screen access API.
The "ViewSrv 11" panic problem described in the document "2-D Game Animation Techniques in C++ for Series 60" alone would keep me away from using the direct screen access API. There is no easy and safe way described to prevent this panic ( there is just vague talk like should, could ). I also doubt that the hardcoded way mentioned in the document and used in the example will work under all circumstances.
If you do not use Direct Screen Access API, you would probably open a window with bitmap on it. In this case you work via Window server and it is very slow.
If you just take the screen address, you need to control the screen mode and events that window server may create.
If you use Direct Screen Access, you can blit fast to the screen buffer and control the events and the screen mode.
You can also get the GC to the screen buffer even if you have partial screen to use.
It's a clean and neat way to do it. Why not use it?