2.2 Front buffers (Front buffer)drawing tiles through Qpinter is really about drawing the pixmap stored in the front buffer. A tile without a front buffer means that it does not need to be drawn.
2.3 Back buffer (backend)the back buffer acts as a screen for tile content (off-screen)The back buffer and can be drawn to the QT widget using a qt brush. In the process of updating the buffer (In the process of Updatebackbuffer), for a dirty area caused by an invalid operation (invalidate), WebKit draws the contents of the dirty area to the on-screen buffer, which uses a brush because there is a scaling request that may have a geometric transformation such as scaling.
webcore::frameview by calling paintcontents to update dirty area . Once the buffer is updated, it is swapbackbuffertofron is switched to the front so that the tile (new content) can be drawn onto the QT widget.
the duties of 2.4 Tiledbackingstorethe Tiledbackingstore responsibility is to manage all tiles, including:
- Define a shard policy (Tiling policies): Includes tile size, coverage area factor, creation delay time, content scaling factor.
- Create tiles: Use timers to trigger the creation of tiles. Timers can also be tiledbackingstore by Function:: Starttilecreationtimer Trigger, once the time is up, Createtiles will execute. When tiledbackingstore attempts to adjust the visible area, Tile creation is scheduled to be performed after the area adjustment.
- Update tile buffers: Similar to tile creation, The update operation is also implemented through timers. When a piece of content becomes dirty, Tiledbackingstore first calculates which tiles intersect the dirty area, and then schedules the update task.
- Freeze status (Frozen State): Tiledbackingstore have nothing to does in Frozen states, for example, it won't update back Buffer and create tiles. THe frozen state was introduced mainly for avoiding time-consuming operations on tiledbackingstore in some Scenari OS, such as content scale. On exiting frozen state by Setcontentsfrozen (false), Tiledbackingstore would check the pending scale factor. If the pending scale was not 0, it had to update the back buffer in accordance with the pending scale.
2.5 tiledbackingstoreclientAll rendering-related features are abstracted to this class, which is an interface, and Webcore::frame is an instance of it, which is responsible for:
- tiledbackingstorepaintbegin: Update tiled backing store must be done before you start. Render engine should make sure the contents being painted to Tiledbackingstore off-screen buffer is correct at that Time, so it had to flush all deferred repaint operation.
- Tiledbackingstorepaint: The rendering engine draws content by calling Webcore::frameview::p aintcontents to Tiledbackingstore the screen buffer.
- tiledbackingstorepaintend: update tiled backing store must be done after the start T. Once the off-screen buffer for Tiledbackingstore are updated, a question naturally comes in the the-the-loop:
"How does UI front know such update immediately" schedule a repaint event to their widgets to draw the C Ontent? Download
THe answer is, at the end of Tiledbackingstore update, it'll notify the Webcore::chromeclient (CHROMECLIENTQT for WebKit Port) to invalidate contents by calling Invalidatecontentsandwindow. In Qtwebkit, Invalidatecontentsandwindow finally schedules a paint event through Pageclientqgraphicswidget to Qgraphicswe Bview.
- Tiledbackingstorecontentsrect Return the content size of Web frame.
- Tiledbackingstorevisiblerect Return the visible area of the graphics item used for drawing Web content. It is actually the visible rect of Qgraphicswebview.
Tiled backing Store (ii)
