Changes between Version 5 and Version 6 of QtWebKitTiling
- Timestamp:
- Jun 22, 2010 2:55:12 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
QtWebKitTiling
v5 v6 27 27 #include <QGraphicsWebView> 28 28 #include <QWebSettings> 29 29 30 int main(int argc, char **argv) 30 31 { … … 61 62 Tiling basically means that the contents of the viewport is separated into a grid of tiles, so that when you update some area, instead of just updating the area you actually update the whole tile. This gives a few advantages for scrolling as when you scroll you do not need to repaint the new visible area for each scroll step, as you update a row of tiles each time; tiles that are often only partly on the screen. This minimized all the paint calls that we have to do and makes it possible to make nicely kinetic scrolling a possibility. 62 63 63 Loading, layouting etc are blocking operations. Though barely notic able on a Desktop machines, these operations can block for a long time on a mobile device, letting the user believe the application has become unresponsive and died. Scrolling which is done by using fingers will also stall and give a bad user experience.64 Loading, layouting etc are blocking operations. Though barely noticeable on a Desktop machines, these operations can block for a long time on a mobile device, letting the user believe the application has become unresponsive and died. Scrolling which is done by using fingers will also stall and give a bad user experience. 64 65 65 66 One way to over come this issue, is to do all loading, layouting and painting (basically all non-UI related work) in another thread or process, and just blit the result from the web process/thread to the UI. When using tiles, you can blit any tile available when scrolling. When no tile is available you can show a checkerboard tile instead, not letting the scrolling wait for the tiles to be updated. This results in a responsive interface, with the only disadvantage that you from time to time might see checkerboard tiles. … … 69 70 For now we will ignore the blocking issue and concentrate on the tiling and the interaction model. 70 71 72 73 [[BR]] 74 71 75 === Resize to contents === 72 76 73 When using tiling, we basically want the QGraphicsWebView to act as our contents, as it supports tiling a.o. things. In order for this we need to make it resize itself to the size of its contents. For this we will use {{{QGraphicsWebView::resizesToContents}}} 74 75 http://doc.qt.nokia.com/4.7-snapshot/qgraphicswebview.html#resizesToContents-prop 77 When using tiling, we basically want the QGraphicsWebView to act as our contents, as it supports tiling a.o. things. In order for this we need to make it resize itself to the size of its contents. For this we will use [http://doc.qt.nokia.com/4.7-snapshot/qgraphicswebview.html#resizesToContents-prop QGraphicsWebView::resizesToContents]. 76 78 77 79 From Qt 4.7 documentation: "If this property is set, the QGraphicsWebView will automatically change its size to match the size of the main frame contents. As a result the top level frame will never have scrollbars. It will also make CSS fixed positioning to behave like absolute positioning with elements positioned relative to the document instead of the viewport." … … 85 87 }}} 86 88 89 Qt 4.7 docs also says: "This property should be used in conjunction with the QWebPage::preferredContentsSize property. If not explicitly set, the preferredContentsSize is automatically set to a reasonable value." 90 87 91 If we are going to expand our mobile web view to the size of the contents of its contained page, then that is going to make the view a lot bigger that what can fit on the device's screen! 92 93 94 [[BR]] 88 95 89 96 === Using a view as the window to the contents === … … 111 118 }}} 112 119 113 In order to properly handle mouse events you must install an event filter on web view or stack it behind its parent object (search for QGraphicsItem::ItemStacksBehindParent). By doing this the mouse events will reach a MobileWebView instance before they reach the member QGraphicsWebView 120 In order to properly handle mouse events you must install an event filter on web view or stack it behind its parent object (search for QGraphicsItem::ItemStacksBehindParent). By doing this the mouse events will reach a MobileWebView instance before they reach the member QGraphicsWebView. 114 121 115 122 Keep in mind that you'll need to add some logic in order to distinguish different mouse events and gestures like a single click, double click, click-and-pan, etc. That is left as an exercise to the reader. 116 123 117 124 Also keep in mind that as stated earlier, scrolling will have to be implemented manually, just as zoom etc. 125 126 127 [[BR]] 118 128 119 129 === Adjusting how contents is laid out === … … 125 135 QtWebKit has a way to force a layout to a given width/height. What really matters here is the width. If you layout a size to a given width, it will get that width and images etc might get cut of. The width/height is also used for laying out fixed elements, but when we resize the QGraphicsWebView to the size of the contents, fixed elements will not be relative to the view, which is the behaviour found on most mobile browsers. 126 136 127 Qt 4.7 docs also says: "This property should be used in conjunction with the QWebPage::preferredContentsSize property. If not explicitly set, the preferredContentsSize is automatically set to a reasonable value." 128 129 http://doc.qt.nokia.com/4.7-snapshot/qwebpage.html#preferredContentsSize-prop 130 131 From Qt 4.7 documentation: "If this property is set to a valid size, it is used to lay out the page." 137 From [http://doc.qt.nokia.com/4.7-snapshot/qwebpage.html#preferredContentsSize-prop Qt 4.7 documentation]: "If this property is set to a valid size, it is used to lay out the page." 132 138 133 139 We saw that this property is automatically set to a reasonable value when using QGraphicsWebView::resizesToContents. … … 143 149 You can play around with this and find your own magic number, but let's stick to this 960px wide for now. 144 150 145 === The 'viewport' Meta Tag ===146 151 147 As some sites do not work with 980 or want to have control on how the page is laid out, QtWebKit as well as Android, Firefox Mobile and the iPhone Safari supports a meta tag called viewport. 152 [[BR]] 153 154 === The 'viewport' meta tag === 155 156 As some sites do not work with 960 or want to have control on how the page is laid out, QtWebKit as well as Android, Firefox Mobile and the iPhone Safari supports a meta tag called viewport. 148 157 149 158 This one also deserves a whole blog post for itself. For now let's just say that this is a meta tag that Apple came up with to make a web page capable of "telling" the browser how it wants to be shown. … … 158 167 http://hacks.mozilla.org/2010/05/upcoming-changes-to-the-viewport-meta-tag-for-firefox-mobile 159 168 160 === Enabling the tiling === 169 170 [[BR]] 171 172 === Enabling the Tiling === 161 173 162 174 We haven't actually enabled tiling yet, so lets go ahead and do that. That is very simple as it is basically a setting: … … 169 181 you might want to take a look at QGraphicsWebView::setTiledBackingStoreFrozen. With this you can avoid updates to your 170 182 tiles during an animation, for instance. 183 184 185 [[BR]] 171 186 172 187 === Avoiding scrollable sub elements ===
