4 ms·
The article is focused on essentially old idea of framebuffers: > Even more ideally these memory chunks would just be textures in the GPU. And that idea is ve
by c-smile 8y ago
The article is focused on essentially old idea of framebuffers:
> Even more ideally these memory chunks would just be textures in the GPU.
And that idea is very far from modern world of high-DPI monitors.
In high-DPI UI you cannot operate on textures anymore.
Window surface shall be represented not by bitmap (that is O(N) complex to fill by CPU) but rather CommandLists:
[opFillRect,0,0,100,100]
[opFillPath,...]
[opBlitBitmap,...]
Window compositor shall pass such command lists to GPU for rendering.
This way to fill rectangle on window's surface will be O(1) complex operation - just to send [opFillRect,0,0,100,100] command to window (and so to GPU) for rendering.
- stefan_ 8y agoI believe you are at the wrong stage, mentally. This is all about the compositor that puts the final image on your screen together. The input to this component is always a list of textures with associated meta information (offset on screen, scaling, alpha mixing, Z position.. whatever your compositor offers). How these textures are created is not the business of the compositor - and the routine case is of course through GPU drawing! There are two things to mention here that are of particular importance on mobile systems. Lots of chips now have compositor hardware - separate silicon from the GPU that can read textures, scale them, blend them and push the resulting pixels directly to the screen. And second, the word "texture" is used here to mean "any format that GPU, compositor and video decode engine can read or produce" - in stark contrast to the old framebuffer approach, it is essential that things stay in their "native" format for as much of the pipeline as possible and are never CPU read or modified, which would require conversion.