After my implementation of local rendering, Flash plays quite well on the N900. In fact, with a plain Qt flash loader (npploader - git://git.forwardbias.in/npploader.git), I get ~70fps. With a QWebView, the fps goes down to around ~50fps. With a QGraphicsWebView, the fps goes to around 55fps. Tested with fps tester.
This is not so bad but youtube was still rendering very badly compared to Fennec. With help from Nokia folks, I found out that the codec being served for Fennec is H.263 Sorenson and Qt/WebKit was being served H.264. The difference in quality would have been blindingly obvious had I paid more attention :-) On the n900, Sorenson Spark is the fast codec that is hardware accelerated (Documented here). If you use N900 to watch Youtube, append &fmt=5 to the Youtube url for better viewing.
Youtube serves sorenson based on the UA and I did some elaborate tests to figure what exactly it was looking for in the UA so we can add the same to Qt/WebKit for Maemo5. The long result is below. The short result is that it expects "Firefox/3.5" and "Maemo Browser" in the UA. Unfortunately, we cannot add "Firefox/3.5" as that would mean Qt/WebKit might get served Fennec optimized sites :(
One options, of course, is to contact Youtube and ask them to serve a different codec for Qt/WebKit's UA but we are not pursuing this because this is really not important :) I have a patch to Qt/WebKit that adds "Firefox/3.5 Maemo Browser" to our UA for *.youtube.com by extending the existing QWebPage::userAgentForUrl(). Simon and Harald are brooding over whether we should bother adding this change. Time will tell whether we will apply it.
Results of the test:
Current Qt/WebKit UA - Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3
Current Fennec UA - Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv:1.9.2.1) Gecko/20100126 Firefox/3.5 Maemo Browser 1.7.4.8 RX=51 N900
H.264 desktop UI
-----------------
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox Maemo
Mobile UI (same ui as m.youtube.com - 3gp/rtsp)
-----------------------------------------------
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser 1.7.4.8
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser 1.7.4.8 RX=51
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser 1.7.4.8 RX=51 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 N900/Maemo Browser
Sorenson + desktop UI
---------------------------
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser 1.7.4.8
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser 1.7.4.8 RX=51
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser 1.7.4.8 RX=51 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 N900/Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox Maemo Browser
Monday, August 30, 2010
Saturday, August 28, 2010
Nice article about accelerated compositing in Chromium
Just found this nice article:
https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome
It is to a large extent Chrome specific, but still a very good read.
https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome
It is to a large extent Chrome specific, but still a very good read.
Friday, August 27, 2010
Last two weeks (33, 34) in Oslo
I missed out the summary of last week because I was travelling, so here are two weeks combined:
- A bunch of us joined a workshop in Boston to work on stability issues with QtWebKit and Qt on Symbian
- We're ramping up QtWebKit Symbian development in Oslo (setting up machines, Jocelyn has been working on making debug builds of QtWebKit for Symbian)
- Work on the HTML 5 Video fullscreen support is progressing with work on transitions from inline to fullscreen in its own git branch. However now we're a bit stuck with framework bugs.
- Our evaluation of using V8 for QtScript is progressing nicely by doing a sample implementation on qt.gitorious.org
- Andreas has been fixing bugs all over the place in the trunk - plugins, GraphicsContext (thx Ariya for reviews), DOM stuff
- Benjamin summarized his SIMD work nicely in his blog post.
Thursday, August 26, 2010
NPAPI/X11 : Plugin Visibility
For the past week or two, I have been working on getting Flash to work on Maemo5/N900. Read more about it here.
Today, I fixed a part of 44594. For mobile, it would be very efficient if Flash gets notified when it goes out of view or when the browser is minimized. There has been some discussion about this but no no consensus. We have to move on and so we have decided to set an empty clip rect in the NPWindow struct to notify the plugin about it's invisibility (I don't like this, I prefer explicit notifications on what is happenning but oh well).
ATM, clip rect is always set to 0 in windowless mode which breaks the above mechanism. So, I set out to find out it's meaning. I found that Flash doesn't care about the value of clipRect at all which made is quite hard to figure what exactly it's meaning is. A note from an Adobe person in the above thread seems to indicate clipRect is actually respected only on the Mac for Flash!
I now set the clipRect based on my understanding of NPWindow. If reading specs is your thing, please read the spec and see if your understanding matches with mine.
Read the spec? Ok, Quiz time.
1. In windowless mode, if NPWindow.x, y = (10, 10) and if the clipRect is (20, 20, 50x50) in _plugin_ coordinates, what should we set NPWindow.clipRect to?
2. In windowed mode, if a plugin of size 100x100 is at position 50, 50 wrt to the page, and we scroll 60 pixels in either direction, what is NPWindow.x,y and clipRect.
Answers
1. clipRect = (30, 30, 50x50). Atleast as per the doc, the clip rect is wrt to drawable and not the plugin's origin.
2. NPWindow.x,y = -10, -10. clipRect = (0, 0, 90x90). The value of x,y is not debatable :) It has to be set to -10, -10 based on empirical data and it's actually wrt the viewport and not the page as the doc suggestes. So, I made clipRect also wrt the viewport.
Good news is even if your answers to the above are different, it doesn't matter because Flash ignores clipRect :)
66095 is the commit in webkit.
Today, I fixed a part of 44594. For mobile, it would be very efficient if Flash gets notified when it goes out of view or when the browser is minimized. There has been some discussion about this but no no consensus. We have to move on and so we have decided to set an empty clip rect in the NPWindow struct to notify the plugin about it's invisibility (I don't like this, I prefer explicit notifications on what is happenning but oh well).
ATM, clip rect is always set to 0 in windowless mode which breaks the above mechanism. So, I set out to find out it's meaning. I found that Flash doesn't care about the value of clipRect at all which made is quite hard to figure what exactly it's meaning is. A note from an Adobe person in the above thread seems to indicate clipRect is actually respected only on the Mac for Flash!
I now set the clipRect based on my understanding of NPWindow. If reading specs is your thing, please read the spec and see if your understanding matches with mine.
Read the spec? Ok, Quiz time.
1. In windowless mode, if NPWindow.x, y = (10, 10) and if the clipRect is (20, 20, 50x50) in _plugin_ coordinates, what should we set NPWindow.clipRect to?
2. In windowed mode, if a plugin of size 100x100 is at position 50, 50 wrt to the page, and we scroll 60 pixels in either direction, what is NPWindow.x,y and clipRect.
Answers
1. clipRect = (30, 30, 50x50). Atleast as per the doc, the clip rect is wrt to drawable and not the plugin's origin.
2. NPWindow.x,y = -10, -10. clipRect = (0, 0, 90x90). The value of x,y is not debatable :) It has to be set to -10, -10 based on empirical data and it's actually wrt the viewport and not the page as the doc suggestes. So, I made clipRect also wrt the viewport.
Good news is even if your answers to the above are different, it doesn't matter because Flash ignores clipRect :)
66095 is the commit in webkit.
Friday, August 13, 2010
Linking problems with LD_LIBRARY_PATH and Maemo/Scratchbox?
I just mentioned the same thing to Alexis, so I thought I'll write it down here so that anyone can find the solution if needed:
Sometimes when building Qt apps in Maemo/Scratchbox you'll notice that when you run ldd on your example app on the device it won't pick up your own build of QtWebKit.so but it'll always use the one in /usr/lib.
I recently heard about a neat trick to fix this:
The binary has a built-in rpath that makes the dynamic linker ignore LD_LIBRARY_PATH, but there's a little tool to fix it up. Just run "fakeroot apt-get install chrpath" in scratchbox and use "chrpath -d /path/to/your/testapp" to remove the rpath altogether. When you then run the binary on the device it'll respect LD_LIBRARY_PATH.
Sometimes when building Qt apps in Maemo/Scratchbox you'll notice that when you run ldd on your example app on the device it won't pick up your own build of QtWebKit.so but it'll always use the one in /usr/lib.
I recently heard about a neat trick to fix this:
The binary has a built-in rpath that makes the dynamic linker ignore LD_LIBRARY_PATH, but there's a little tool to fix it up. Just run "fakeroot apt-get install chrpath" in scratchbox and use "chrpath -d /path/to/your/testapp" to remove the rpath altogether. When you then run the binary on the device it'll respect LD_LIBRARY_PATH.
This week (32) in Oslo
What are we up to in Oslo this week? Here's a quick summary:
- We continued with our evaluation of V8 with prototyping QObject bindings (http://bugreports.qt.nokia.com/browse/QTBUG-12503).
- Work is progressing on creating a prototype of full screen playback of HTML 5 video elements on Maemo (http://bugreports.qt.nokia.com/browse/QTWEBKIT-236).
- Ramping up for Symbian^3 and Symbian^4 bug fixing.
- Investigated crash with arm jit on Maemo5 / N900 (https://bugs.webkit.org/show_bug.cgi?id=43910 - Thanks Loki for the fix! :)
- General release management work and helping to get the qtwebkit-2.1 branch packaged separately for Meego and Symbian.
Thanks all folks :)
Friday, August 6, 2010
Introducing the Journal
This blog will be a journal of honest, unmoderated and unfiltered entries from the developers working on the Qt port of WebKit.
Anyone contributing to the project is welcome to write down their thoughts in this journal - from code changes to product management findings and updates. It will be a journal from contributors for contributors, that will give insight in what people are working on, what challenges they face and what cool things they achieve. It will also be an archive of knowledge that we can search in.
At this point I don't have any intention of advertising this journal to a wider audience, i.e. by aggregating it to planet.webkit.org. Let the word spread among contributors where to find it :)
If you'd like to write entries in this journal, please send me a message and I'd be happy to add you to the authors.
P.S.: I have to give credits to Espen who is now working at http://cutehacks.com/ . When he was leading the Windows CE and Symbian ports of Qt he had created such a developer's journal that turned into a great resource, because everyone in the team contributed.
Anyone contributing to the project is welcome to write down their thoughts in this journal - from code changes to product management findings and updates. It will be a journal from contributors for contributors, that will give insight in what people are working on, what challenges they face and what cool things they achieve. It will also be an archive of knowledge that we can search in.
At this point I don't have any intention of advertising this journal to a wider audience, i.e. by aggregating it to planet.webkit.org. Let the word spread among contributors where to find it :)
If you'd like to write entries in this journal, please send me a message and I'd be happy to add you to the authors.
P.S.: I have to give credits to Espen who is now working at http://cutehacks.com/ . When he was leading the Windows CE and Symbian ports of Qt he had created such a developer's journal that turned into a great resource, because everyone in the team contributed.
Subscribe to:
Posts (Atom)