qt webkit goes Mobile
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 64 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45946 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Mobile WebWeb browserDivisoroutputGoodness of fitMobile WebWebcamWeb browserWater vaporForm factor (electronics)TouchscreenKeyboard shortcutDifferent (Kate Ryan album)BootingComputer animationXMLLecture/Conference
00:46
TrailData modelProcess (computing)Web pageInternetworkingDivisorStructural loadTouch typingContent (media)Mobile appZoom lensAreaSystem callInteractive televisionDependent and independent variablesProcess (computing)Web pageTouchscreenInternetworkingMultilaterationWeb browserContent (media)Link (knot theory)Level (video gaming)Real numberDifferent (Kate Ryan album)Mobile appWeb applicationForm factor (electronics)Mobile WebTouch typingFitness functionConnected spaceCoprocessorCuboidPairwise comparisonRow (database)AreaWeb 2.0Software development kitPlanningLimit (category theory)Personal identification numberTrailZoom lensSpacetimeCollisionRoboticsView (database)ChainGoodness of fitPhase transitionExecution unitEmailPhysical lawClient (computing)Network topologyNeuroinformatikBitPresentation of a groupLecture/Conference
04:35
DivisorAndroid (robot)Computer fontClique-widthAreaPersonal identification numberZoom lensBitDot productQuicksortContext awarenessAndroid (robot)Lecture/Conference
05:09
NP-hardNetwork topologyPosition operatorDigital electronicsZoom lensTouchscreenOrder (biology)Musical ensembleAreaAndroid (robot)View (database)MathematicsLine (geometry)Category of beingLatent heatLecture/Conference
06:15
Content (media)TouchscreenAreaWeb pageKinematicsSet (mathematics)Maxima and minimaAreaComputer fontProcess (computing)CurveExecution unitClique-widthWeb browserLecture/Conference
06:46
AreaAreaZoom lensDifferent (Kate Ryan album)Clique-widthBitQuicksortGraph coloringCodeSpacetimeLecture/Conference
07:40
CurvatureComputer fontDivisorAreaClique-widthNP-hardAndroid (robot)Content (media)TouchscreenWeb pageKinematicsFeedbackPressure volume diagramSimilarity (geometry)Boundary value problemPersonal area networkVertical directionSoftware testingSpacetimeGoodness of fitBitGreatest elementPoint (geometry)PixelAreaPersonal area networkTouchscreenAndroid (robot)Dot productSurfaceFrictionGraphics tabletWeb pageInfinityControl flowServer (computing)Water vaporMultiplication signNeuroinformatikBootingEvelyn PinchingDifferent (Kate Ryan album)Price indexWeb browserKinematicsCausalityOrder (biology)StatuteImage resolutionMobile appLecture/Conference
11:13
Chi-squared distributionContent (media)TouchscreenAreaWeb pageKinematicsHeuristicSoftware testingGeometryThermal expansionFrame problemBitRight angleAreaDirection (geometry)Touch typingSoftwarePRINCE2DiagramCompass (drafting)Software testingWeb 2.0Point (geometry)Multiplication signRow (database)Link (knot theory)Form (programming)Web pageContent (media)Frame problemAlgorithmSet (mathematics)Lecture/Conference
14:20
Web pageBlock (periodic table)Content (media)Touch typingWeb browserTouchscreenWhiteboardComplex (psychology)Flow separationThread (computing)Read-only memoryAreaSequenceProcess (computing)Graphical user interfaceInformation securityElement (mathematics)RotationTesselationComputer-generated imageryPersonal area networkContent (media)Medical imagingElement (mathematics)Process (computing)Web 2.0Shared memoryGreatest elementWeb browserMultiplication signAreaInstance (computer science)Zoom lensAndroid (robot)NumberThread (computing)Different (Kate Ryan album)Web pageRotationDecision theoryParameter (computer programming)BuildingNatural numberCuboidType theoryPRINCE2Symbol tableWechselseitige InformationBitOnline helpCommitment schemeSequenceWordLecture/Conference
18:37
Computer-generated imageryWeb pageAreaPressure volume diagramSynchronizationWhiteboardMobile appRotationPersonal area networkStructural loadProcess (computing)Zoom lensScale (map)Control flowContent (media)RectangleLine (geometry)Vector spaceDivisorInstance (computer science)Clique-widthTouchscreenScaling (geometry)AreaTesselationMaxima and minimaRotationClique-widthGoogolSynchronizationBitWeb 2.0Normal (geometry)DivisorContent (media)Different (Kate Ryan album)Structural loadCuboidMultiplication signSuite (music)Web applicationSemiconductor memoryView (database)Shared memoryPrice indexMedical imagingKeyboard shortcutWeb pageProcess (computing)MereologyTablet computerPower (physics)Spring (hydrology)CASE <Informatik>Task (computing)Food energyFormal languageRectangleSound effectReal numberOrder (biology)Observational studyGraphics tabletInstance (computer science)Suspension (chemistry)CountingConfidence intervalLattice (order)MathematicsWeb-DesignerLecture/Conference
23:44
Clique-widthGoogolRotationRotationView (database)Content (media)SmoothingClique-widthHypermediaEntropie <Informationstheorie>SpacetimeBitBoss CorporationFamilyTheory of relativityLecture/Conference
24:33
RotationStructural loadContent (media)Mobile appPresentation of a groupSoftware developerPersonal digital assistantPixelScale (map)Web pageIRIS-ToutputTouch typingEvent horizonWeb browserMobile WebAdditionMultiplicationProcess (computing)Clique-widthDefault (computer science)Meta elementControl flowAsynchronous Transfer ModeMaxima and minimaAndroid (robot)Revision controlEndliche ModelltheorieIndependence (probability theory)Population densityTemporal logicExtension (kinesiology)Flow separationFocus (optics)Beta functionWebsiteScaling (geometry)Clique-widthMaxima and minimaWeb pageAsynchronous Transfer ModeMeta elementGame controllerTouch typingWeb browserMedical imagingWeb applicationContent (media)View (database)Level (video gaming)outputPixelMobile appDifferent (Kate Ryan album)Population densityAndroid (robot)Perfect groupCartesian coordinate systemComputer fileGreatest elementImage resolutionFlow separationFocus (optics)Personal identification numberWeb 2.0Figurate numberEvent horizonPresentation of a groupLink (knot theory)Normal (geometry)CASE <Informatik>Process (computing)Data storage deviceStress (mechanics)SpacetimeSampling (statistics)Noise (electronics)Instance (computer science)Information overloadPoint (geometry)SoftwareAlgebraHypermediaType theoryWindowCubeMereologyFitness functionMultiplication signMusical ensemblePrice indexAreaTouchscreenCentralizer and normalizerGoodness of fitLecture/Conference
31:27
Web browserFlow separationEvent horizonFocus (optics)Mobile appControl flowContent (media)AgreeablenessDatabaseWeb 2.0Multiplication signCartesian coordinate systemWindowMereologyBitFerry CorstenNetiquetteScheduling (computing)ExistenceUniformer RaumMedical imagingAreaLevel (video gaming)Hand fanStaff (military)Game theoryGeometryTexture mappingAcoustic shadowGraphics tabletContent (media)Scaling (geometry)Computer fontSemiconductor memoryProcess (computing)TesselationWeb browserPersonal identification numberEvent horizonDecision theoryMathematicsOrder (biology)DistanceEndliche ModelltheoriePersonal area networkShared memoryReal numberComputer animationLecture/Conference
38:21
Lecture/ConferenceXML
Transcript: English(auto-generated)
00:07
To make a pretty good mobile web browser, you use your webcam. We have Android, we have iPhone, we have the browser, the blackberry torch, and we just see more and more. There's also less boot straining because a lot of the pieces needed to make a good mobile browser is already in place.
00:27
So, we're targeting a totally different form factor than a desktop browser. On a mobile device, the screen is usually quite small, which makes for a lot of different problems. And we're not using a keyboard, we're not using a mouse to navigate.
00:43
So we have a totally different input. You might say to yourself, well, Nokia hasn't been really good at doing web browsers. The track record isn't really that good. Well, you can say that today, that might be true, but actually, Nokia was the first company that bought a web kit to a mobile platform.
01:04
And they did that many years ago. And they did pretty well. But there's a lot of things that's changed since then. Since today, there's Wi-Fi everywhere, there's access to 3G, the cost plans are a lot cheaper than they used to be.
01:20
Before, people weren't really using an instant browser on their mobile phone because it was really slow, it was really expensive, and it couldn't really render the real web pages, so we had to get these web pages with limited content. And it wasn't really what people wanted. So a lot of these things have changed. Today, we have nice data plans.
01:41
We have larger mobile screens. We are different, we are interacting with the country, using touch-ups, using your fingers. And we have more powerful devices. So this means that today it's possible to integrate the real Internet into mobile devices.
02:01
You have more screen real estate, and you have more powerful processes. So you can actually load these real pages and process them and show them how to use them. But there's a lot of challenges in making a mobile web browser. First of all, as I mentioned, we have a small form factor. Things just don't fit on the screen.
02:22
You can't really see a whole page. Then you might have to make it smaller, and then the text is so small that you can't really read it. So there's a lot of different issues. Another problem is loading the page from the net. We're having a slower net connection. We also have to understand, pass this on a slower processor.
02:41
Then we have to go through the layout page to figure out where should the text be. Should it be reflown? Should it be a box here? We have to do all this before we can paint. I think we have to paint. So that's very slow in comparison with a desktop browser, where we have maybe a phone call computer.
03:00
Then there's something very, very important. Touch interaction requires a very responsive user experience. I'll get into that a bit later. Also, fingers are pretty huge. So you're trying to click a small link with a big finger, and you can't even see what you're thinking. Because content is small, so you normally zoom out.
03:24
So you can't see it. We'll talk about that as well. There's also the web apps. People are trying to make web apps today, like email, clients, etc. So that brings a whole lot of different challenges. But we'll talk about that at the end of this presentation. So let's look at the small phone app.
03:43
There are already some really, really great ideas on how to deal with it. The first is zooming. It needs to be possible to zoom out or zooming to look at what's interesting for you. Some good ideas. For instance, you can do a double tap to zoom a specific area of the page. For instance, if you've been on a news page, like the New York Times,
04:03
double tap on one area, and it will zoom in. I think I should have an example of that for you. At the New York Times, a double tap on a large table, and there's a map in the zoom center, so you can read it. This is not perfect. And there are areas where you can't find these nice areas to zoom into.
04:23
So you also want it to be able to do that manually. So people can make two pins zoom in. With two fingers, I want to see this area. Maybe in the roof, the page around it. Pins zoom, I don't know if you can see the two dots, and the two fingers are trying to pin out.
04:41
So I can see the whole page, and we'll probably just go back and pin zoom in, so we can do a little bit more buttons. But there's still a lot of issues. Even though you saw that I zoomed in here, it might be that the text, that column is pretty wide, so the text becomes so small that it's impossible to actually read that.
05:04
There are different solutions for fixing this. Android comes with something called text reflowing. I have an image of this, the same article. I don't know, it's pretty dark. It means that when you zoom into something, you don't want it to become the whole text here. And in order to be able to see it, you have to zoom into this area.
05:22
So you have to read here, scroll to the side, read the next, scroll back to start the next line. And that's pretty annoying. So Android, they fixed that by reflowing the text. So it means that when you're in a specific zoom level, you just relay out the text so everything fits into one view.
05:40
This is something that's really, really hard to get right. I don't know if you've ever tried Android. Sometimes it just doesn't work. And you end up with text that's always outside the view. You try to move it a bit, it's still outside the view. Because it doesn't reflow again. Something else that I've said before, doing that by the audience is really expensive. So it can interrupt the user experience.
06:02
And that's the third issue, is that when you zoom in, you get this nice animation that everything zooms in, and then everything just changes position. So maybe even what you wanted to see is now outside the view, outside the screen. So the iPhone has a different solution for the same property. It's known from desktop browsers that you can have a setting
06:23
of minimum font size, enforce this minimum font size. Never show font smaller than this. Jonathan brought that a bit further. He said the minimum font size is per width. So when you can double tap some area, they enforce the minimum font size when you zoom in to the area.
06:45
So if I zoom in to this area again, they'll say, well, the font size of this area has to be 10. Or 12. This means that the original page, you'd like to see that. Maybe the font size in the first column is like this one,
07:02
and then in the middle column, because they have a better, wider width when zoomed in, the font size might even be bigger. I think none of you have noticed that on the iPhone. You don't really see it. If you know it's there, you can go to New York Times, this page, and you'll see that sometimes in some columns,
07:21
the wider the columns are, they often have increased the font size a little bit. It doesn't annoy people. It just makes sure that you always get a nice animation and it's always possible to read the text and zoom in. But there's a lot of different ideas, and there's probably new ideas that can be explored as well to solve these issues.
07:45
So, let's get back to the fingers. As I said before, our fingers are pretty big. So it's really, really difficult. On a computer, you're having a mouse that has one dot. You click on one specific point. On a finger, it has like a surface you're clicking on.
08:01
And many times, people are even shaking. It's really, really common. Everyone shakes a little bit when they try to click on something. There's a little friction there. We remove the pace a bit. So, we need solutions when we're dealing with these things. Like I said before,
08:22
this pace is that one of the problems we have in this conference is that you look at some little area and you want to go to the next area. You need to be able to pan around the pace pretty fast. On a distant browser, you only have a big screen, so you see everything, and first, a little later, you start scrolling a bit.
08:40
On a mobile page, you often zoom in to some specific area, and you want to be able to get an overview and get back zoom. So the double tap is pretty good for zooming in to a specific area. And you can do it the same way that if you double tap the same area, you zoom out so you get an overview. Still, it doesn't solve everything. On that pace, you don't even have zoomable areas.
09:03
Maybe just text. So you want it to be able also to pan around fast. So, it may be possible to pan around with your finger, like if you're on Android or your iPhone, but still also if you pan a bigger area, with a little force, it will start doing some kinetic scrolling,
09:21
making you scroll faster, so you can easily get to the points that you want to see. Also, as the screen is pretty small, you don't want your scroll bars. It's not nice, clean scroll you want to pan. It's beautiful and natural,
09:41
and it also takes some space on your screen. So most mobile browsers, they don't show scroll bars. Instead, they use what are called scroll indicators, things that show themselves when you're panning or pinching, and then disappear when you don't need them. Because when you're panning, for instance, anyway,
10:00
you're panning pretty quickly and you're not reading anything. So it's pretty good. You can just look at the sides of the scroll bar and you can see if you're at the top or at the bottom. You can also make other ways to show that you reach the boundaries, like the bottom of the window, or just by doing a bounce screen, or make your cell phone shake a little bit.
10:21
There are different ways of doing that. As I said before, fingers often shake a little bit, also when you click. So it's always a good idea to have some thresholds, like when you click before starting panning, you say, okay, you have to move like 10 pixels. Before you start pinching, you have to move 10 pixels
10:41
just to ignore all these small, imprecise movements that people make. So this is very common, and you'll notice that if you take an iPhone and Android, this is included in this one. You start pinching, you can pinch like maybe 5, 10 pixels before it starts pinching.
11:00
And the same thing with moving. Which means that if you click on the bottom, it doesn't start moving the page, or the connecting scroll is probably really annoying. Another way is that if I'm trying to pan or zoom into a page, like this one, I start to pan, it's very, very difficult to do a movement straight up.
11:21
You always move it a little bit to the right or to the left. So you can try to guess or look at the various, you find out, okay, the guy is probably going to pan off the opulence, and then you just ignore it, unlock it in that direction. So you don't, if you're really an artist,
11:40
you will suddenly scroll out of it, and then you'll have trouble scrolling back again. So there are all these different small tricks you have to apply to use touch. Something else, as I said before, is that on fingers, when you click on the device, you have a touch area.
12:02
So you'll need to find out like a point where you clicked. Normally, this could be the touch area you get from the touch point, and normally you can do another user testing, but people actually want to click a bit above that area, like where I put the dot here. So you can take that as a starting point. But instead of just looking at what's below it,
12:22
because most of the time you actually listen, because you have big fingers, they're unprecise, and you can't see where you're clicking. So we use an algorithm in WebKit that will try to figure out whether anything's clickable in this area where it clicks. So what's that link just below it, so the user probably wants to click on that link,
12:41
and then we will click on that for the user. Another big issue with having scrollable content and using your fingers and scrolling is that we want it to be like one area that you're scrolling. It really confuses people. If you're scrolling, suddenly you hit some area,
13:02
a soft area, and it's scrollable. Then it really confuses people, because suddenly it starts scrolling differently. It could be like a page that has frame sets, or a page that has like iframes that are scrollable. So, for instance, what the iPhone does is it says there are no scrollable iframes.
13:26
So they simply expand the iframes to their size, to the size of their contents. If you would think that something that would break a lot of pages, but it cracks, it doesn't. They do the same thing for frame sets we also do. For instance, this is a test, one of the WebKit tests.
13:43
It shows the frame set, it's a bit strange. But you see like if you had this on a small phone, that would be really difficult to read the text. Here you have to pan a little small area, here you have to pan this area. You just want everything to be like one big area that you can pan. So the idea is that we expand all the frames to their contents area, and then sometimes we get
14:05
some area that occupies and we expand these other frames a bit further. So we get something like this. So this is the frame set, frame planning enabled. So you get one big area that's scrollable.
14:23
So the conclusion is that TUS is a really, really nice way to interact with web browsers. It feels very natural, it feels easy. But there is one huge issue. If you really feel it if the page is blocked. Like I said before, if you have a desktop browser,
14:41
you open up, you have a big desktop browser, you load the page, there's the contents, you always see everything you want to see, and then you start scrolling. So now you start scrolling when it's already finished loading. Or even if it blocks a bit, you don't really notice it. But on a mobile device, that's slower. When you're using your fingers, you really feel when things fall.
15:05
And browsers, they stall out. They do that during loading.
16:07
The most common idea is to separate the UI and the web. I have different threads on different processes. One way to do it is that you have a web.
16:21
Let's just talk about the UI process and the web process. So you have a web process. It will paint something, it might store the painting sequence, send it to the UI process, you can repaint it. This is from what I know is what they're doing on Android. Or you can share the painting area. It paints into some shared memory
16:41
of the web process when you're ready. You can show it on the UI process. What is really important is that everything is non-blocking. So you need to design a whole new API to make sure that you can do almost everything non-blocking. Because if something blocks, everything blocks, and you view it.
17:03
There's one example I've written down here. Think about it. It paints like fixed elements. So if you have fixed elements, it has to always be in the bottom. As in the web engine that's painting it, every time you scroll, you have to tell the web engine I scrolled, and you have to tell it back. But it's pixel.
17:21
Okay, this, it'll have to paint and to re-update. If we did it this way, it would be blocking the whole time. So we have to find solutions for all these small chronicles. And I'll tell you, there are a lot of them. Sometimes it's not the perfect solution. It breaks contents.
17:40
Like the iPhone does for fixed elements, for instance. I believe there are very few mobile browsers that support that. I have some good ideas how we can support at least 90% of fixed elements. But there are all these different issues we have to solve. And it's really important we do this while people are panning,
18:02
pinching, or while we do the rotating. Our solution, this is similar to what they're doing on the Blackberry and what they're doing on the iPhone, is using a synchronous title. It means that we look at the whole content as one big image.
18:24
Like, we paint the whole content into an image. Then you can pan an image. You can scale, like pinch, zoom an image. And you can rotate it at 60 frames per second. It's like the magical number. So, here's an example.
18:40
The green part, that is our screen. It's what we're currently looking at. And the gray and blue area is like the content. So the content is divided into different tiles. Some of these tiles I call X tile because I've changed the size of it because I want to be able to still maybe pan out and maybe pan back.
19:05
You know, want it all to be shown. But this is the basic idea. So, when a tile becomes visible when you're scrolling, if it's already painted by the web process, which we're doing with shared memory or memory met.io,
19:22
well, then you can just blend it. Just paint that tile on the screen. If it's not available, we can do some indication that the content is not ready yet. For instance, by painting checkerboards. This is something that's known for most of the images at the case, like Photoshop or even the iPhone is using.
19:42
Like, the content is not ready yet. We need a shortcut. This means that we have decoupled the whole web engine from the UI. The UI just paints tiles, images, that sometimes get updated by the web process.
20:00
Of course, pages, they change. There are images, there are calendars. So, when a page changes, like when we work with tiles that are visible, we first have to update it. We don't have to repaint the whole tile. Or we just paint, like, the area. We have to make sure that we paint the area for all tiles visible, so that all tiles stay in sync.
20:22
You can't have, like, for instance, the tiles outside the view that wasn't updated, and what's inside the view that got updated, because then you might see that when the tiles interact, that here it's painted and here it's not painted. Like, if you have a blue box, you see the blue box here, but the blue box isn't up here or here. So, all the tiles have to always be in sync.
20:44
When you get updated, we need to do tiles outside the screen. A common idea is to store, like, a dirty region. You don't need to paint it right now. You just mark this area of the tile as dirty. If you get another dirty area from the same tile, you might just merge those two areas.
21:00
Or, if it's too big, you just might just discard the whole tile and then paint it a whole tile next time. So, this is not exactly enough to get, to make sure the device is, like, at 60 frames per second for padding, painting, or rotation. Because we're having the repaints, we're having loading,
21:21
we can have the load wire in hand, and we can create JavaScript executing. So, the basic idea is that you just suspend all JavaScript, your pen, your engine, your rotate. People don't care because of it. You suspend JavaScript, you defer loads. If there's a load going on, do it later,
21:41
and people are finished panning, and they know the repaints. Because people don't care about these things. You don't notice it, but it just makes sure that we can really paint things the same frame per second. This wouldn't be possible, for instance, if you did a paint suit on a page, I don't know how long it would take to repaint that area.
22:02
Because there might be more text, there might be more rectangles, it might take a bit longer. So, when we do a paint suit, we do something more. We don't paint anything. So, basically, we store the whole tiles. We keep the tiles where we had, and we just scale it, just like an image.
22:22
Because to figure this whole tile is one big image. You just scale it up, and you can do that 60 frames per second without problem. When you're finished, you repaint everything. So it's nice, sharp text. It's readable.
22:40
Rotate is also a bit tricky. Normally you want to see the same thing. If I'm looking like a portrait, I'm really glad that this comes in front of the flooring. Flavoring, so I'm monitoring, it should just scale up so I'm looking at the same area. So that's the basic thing. Look at the difference between the width and the height,
23:03
and multiply and divide with that factor depending on how you're rotating it. The iPhone did a bit more. They can make it possible for web developers, web authors, to decide on what should be laid out. This is something that's particularly very important for web applications.
23:22
For instance, if you look at the Google page, they make it meant as web apps. It says, like, the maximum scale is one. Don't do this scale up when I'm rotating it. I don't want it. So it would be, if we look at normal Google here, rotate it, there's some area missing here.
23:44
So what we do, with all the honesty, with Android, with iPhone, with everyone I'm doing, you can say, well, you've been doing this today, you've been over at iPhone for a little while, is that we have to relay up with the new view. We just said, OK, it doesn't fit. We relay out, and it comes as a width that was larger.
24:04
Basically, like what you see there. But we don't want to do these relay outs while we rotate it, because then we can't ensure the 60 frames per second. So we have the above as a middle step. You rotate it. You keep the content in your hat.
24:21
Just paint some checkerboards or something else in there where there's no contents. And when you finish, you relay out. So you get a smooth animation, rotation animation, and then you get the contents that you want. So summing up, you freeze the backing storage, you spend the JavaScript paint, et cetera.
24:42
You keep the old contents, rotate, and then you relay out with unfreeze. So let's go on to web apps. I'm not going to detail why people should make web apps when it makes sense, when it doesn't make sense. I haven't made a lot of presentations about that.
25:01
There's a link here for those people who are interested. I think I'll be glad to be able to get on the Boston page later, so you'll be able to check that out. But let's just say that web apps make sense in a lot of situations. So how do we know about supporting this? Well, the idea with web apps is that they should be paint-like real apps.
25:22
What does that mean? Well, it means that one CSS piece should be like a device pixel. You don't want it to be scales. Not all apps don't have a scale. You don't want to have pins, so at least not the whole application, because normal applications don't have that.
25:41
And you want to be able to control the input, touch input yourself. So for instance, you could implement in your web app like paint, buttons, pins soon, et cetera. So mobile browsers would use situations called touch events, which makes it possible for the pages to deal with the events
26:03
in the way they say, see fit. But that also means that every event we get touch event, we have to send to the web process, which we then have to handle it or ignore it. If it ignores it, it has to go back to us, and then we can go up anyone's hand.
26:21
But it means that we get this dependency that was slowed down, sent to the web process, wait for it to return, which is what we don't want. So there's a trick that can be applied. You can change the page that you registered and listen to the touch event if you didn't, don't send the event to the web process, just deal with it on the UI side.
26:44
For controlling the layouts, the iPhone, there has been a lot of different ideas for doing that, a lot of different meta types, but the latest one was introduced by the iPhone. It's called the new phone beta tag, and it's been quite popular. It's used on most of the mobile pages out there.
27:02
Basically, the iPhone will lay out every content as your web browser has the width of 900 megapixels. On Android, the device manufacturer can decide when they want it to be 980, 1,100, or some values like that. They have a few values to choose between.
27:21
For instance, if you even open up the Apple site with 980, it won't fit, because they have this big image on the top that is larger. So there are leads that need to be laid out with a larger view. So they added this meta tag to give this control
27:40
to the level and to decide how to lay out content, how to deal with scaling, etc. So the feature says that you can define the layout width. You can even define the height. It's not very used, but it's possible. Then you can define the initial, the minimum, and the maximum scale. So you can control whether or not you can zoom in or zoom out.
28:03
And it seems possible to just disable or enable user scaling. So here's a few examples. This is one example that shows how it could be done. I have to say that this is defined in portrait mode. For instance, the original iPhone had 320 pixels,
28:23
and the DVI had 160. So this would be to make a picture perfect on an iPhone. So you set the width to 320, and then the maximum scale of one. So you can't scale in or do anything else. Today, as people have told me,
28:42
devices with different resolutions, etc., it's possible to define that device width. So if your device is 480, it will lay out as good 480 as it did. One of the big issues with web pages and web apps is that,
29:03
for instance, if you have a button, a button, a scroll bar, whatever you have done, how it's shown to the user the size of the app, like how it is picking and compressing your fingers, that depends on the DPI of the device. If I have a high DPI, it might be so small that I can't really interact with it,
29:21
and that's not what you want for a mobile app, for a web app. So I set the iPhone as a DPI of 160. So when this problem starts to arise, especially with Android phones coming out with DPI of 240, people start to figure out how should we resolve this issue.
29:41
So Google, they made a definition of something called density within a pixel, and that's defined as a pixel on a 160 DPI phone. That is because most, if not all, web apps today are designed with the iPhone in mind. And now that Android and the other applications
30:02
are not exactly the same, this is how it's going to work. So if you look at the French Firefox and the Nokia N900 on the other Android devices, the DPI of 240 or beyond, they actually scale up the content. So if you had a 320 on the page,
30:22
you would have to scale it up by 1.5, by 2.4, by 2.16. This is not what you always want, because, oh, I bought this really nice device, and it's a beautiful screen, nice DPI, why is it going to scale up? So Android has something called a target density DPI,
30:43
but it's possible to override it. By default, it's set to, I think it's called a medium DPI, which is 160, but it's possible to set the presence of device DPI. And then via CSS, figure out if it's scaled or not, so you can load a different CSS file
31:00
with better resolution, with images, bottom users with better resolution. So, summing up, making a mobile browser with touch devices has a lot of different requirements than making a desktop browser. Our focus is on the touch interaction, on seeing your content and interacting with it.
31:23
So when you touch the bench, you need this engine application separation and a lot of small tricks to make everything work perfectly. I've just shown a few of them today, but there's a lot more, a lot of ideas you can do to make this really work. And for doing web apps,
31:40
the application needs the support of the web order to decide whether the browser should support scaling, maybe whether it should even show the Chrome, et cetera. So, I hope you have enjoyed the show, and I hope that you have some good questions.
32:06
Yes? No? The Q-bucket? No, the Q-bucket is based on a normal Q-bucket.
32:23
Cool. I guess you can do that. Just like I said, it's based on a normal Q. So whatever Q can run on here, it can run on.
32:40
So you could use Q.US. You can even, if you want to, use Windows Mobile, but it doesn't support it. It's used to use. I think because Q is possible.
33:11
Well, having the 60 frames per second is something that... Okay, sorry. Well, he was trying to ask about
33:22
issues like QWIS on an event platform with Q, how you can ensure having like 60 frames per second. It's not something that me and Q can ensure that you have 60 frames per second on a Q device. It's something the device has to provide. If the device can perform like 60 frames per second for panning,
33:44
pin zooming, and rotating an image, well, then with this idea and detail today, it's possible. Because the painting is done separately from showing it. It's done in the work process. For instance, on most mobile devices,
34:02
you can make these tiles like maybe OB-GL textures. So the shared textures you write to them, the scale and everything is done in the graphics file. You will need to provide a platform that can give you 60 frames per second for doing the painting, panning, rotating,
34:20
and rotating an image. And there's something you have to be careful about, that is the texture upload. If you use something with OB-GL, these are different tiles. It's not just one image, it's a tile image. It's made out of tile. So every time you have to blend something, you have to maybe upload that texture in real memory.
34:40
If that is too strong, you might see it stop a little bit while panning. Do you like it? Yes. For instance, you mean the actual image.
35:00
How does it compare to the actual image? Not really. The way this can be done is, like I said, you would use a shared memory area so you can implement it the way you want. This is just basically the idea of how you would implement taste. It can vary depending on your hardware, et cetera. Yes. You mentioned people said you want a separate
35:24
so that you can get a specific model. Is it possible to take these images and then paint them outside of the visual area? Is it often necessary or is that too much?
35:40
Well, you can do some things of course. If you're panning, you know something. Actually, having a tile is always a bit what you're saying, because I'm painting a large area. So if I already have a tile outside the area, I might make a decision that
36:00
always paint two tiles outside of the visual area. And then just paint them when they're ready. So you just schedule a layout, say, paint these tiles out of the image, but don't paint them all the time because the memory will shrink as well. So it's all like a trade-off, something that is performance.
36:20
You have to try to work with your sense so it gives the best user experience. Of course, the idea is that you shouldn't use all the memory of your device, and you should try to make it possible to make it almost impossible to see the change of all the images so that you don't want it to be the whole time. But there's a lot of things that you can design.
36:44
Do you own the DPI scale for the full distance of the wire or the schedule holder? Well, the DPI I was talking about, he was asking whether we will only use the DPI for the font scale or for everything? Well, with the DPI in the new font,
37:03
we'll use it for everything. Also images? It's basically, as I said, we're painting the content with the scale. So we just take the DPI into account. Any other questions?
37:37
He is asking, how responsive should the application be
37:41
for a user to notice it? Well, that is basically what the 60 frames per second is about. That is what your eye can register. So that you can do better than 60 frames or at least 60 frames per second. Then that's what you should aim for. You don't really need to have something like 50 frames per second or more than 60 frames per second.
38:03
You don't really need that. Unless the user can proceed. Okay, thank you very much for coming.