gfx/window_android.h

One surface, composited here

A desktop has windows: the editor is one, a popup menu is another, a tooltip a third, and the OS stacks them. An Android activity has ONE surface, an ANativeWindow the size of the screen. So the peers here are LAYERS of that surface: AndroidSurface keeps them bottom to top, paints each into its own Backing as the desktop peers do, and copies them into the window's buffer in order -- the editor, then whatever menu or tooltip is open over it. A touch goes to the topmost layer it lands on; a touch outside a menu that grabs the pointer dismisses it, as a click outside one does on a desktop.

Pixels go straight in

The rasteriser's bitmap is R G B A, premultiplied, and so is the window's buffer (WINDOW_FORMAT_RGBA_8888): rows are copied, nothing converted. Only what changed is copied, through the window's dirty-rectangle lock, which hands back the previous frame around it.

Touch, pen and mouse

Fingers arrive as AMotionEvents with a pointer id each. The first finger down is the PRIMARY pointer: it moves the focus and goes through the router as the mouse does; the others are delivered as touches of their own (MouseInputSources). A stylus is a pen with pressure, a mouse (a Chromebook, a tablet with a trackpad) is a mouse with hover, buttons and a wheel.

Scale

The surface's density (dpi / 160, AConfiguration) is the scale: a phone at 420 dpi draws every logical pixel as 2.625 device pixels, which is what makes a 24-point control the size of a fingertip. The app sizes the editor to the surface's logical size (android_app.h).

The UI thread is the activity's main thread; every call here is made on it.