WebPirate
WebPirate copied to clipboard
Dax89
devicePixelRatio is reported wrong
Currently WebPirate reports a devicePixelRatio of 1, while it should report 1.5 as the default browser. Check this test for instance:
http://twister.43foldrs.com/dpr.html
Thats an issue I also have on Webcat. The issue is upstream in qtwebkit that uses a autodetection of devicepixel ratio. The qml bindings for manipulating it were removed. Not sure about c++ bindings but they changed this with qt5.1 onwards and I didn't find how to set this yet.
Yeah, llelectronics is right: currently it cannot be changed from Qml. I'll keep this bug open and I will update the post if I find a workaround.
I was making report, but maybe it's just depending of this? Site eg. http://thingiverse.com/ leaves white borders side of screen. With default browser it shows as right size.
I found a hack that works at least in webcat. Feel free to use this aswell. See the userscript.js changes from here: https://github.com/llelectronics/webcat/commit/dd52155d9d9932a36c81012c4dab1a7893640441 It only works on mobile sites though.
I've experienced some reproducable crashes of the rendering engine in v0.92, maybe related to the 'DevicePixelRatio-hack'. Example: www.tagesschau.de
@Moth2015 I also noticed that for tageschau.de . But no other websites so far. This particular website is basically very poorly coded. Its a nightmare. Basically they have a javascript running in the background checking the screen resolution and changing the appearance based on this. This conflicts with the javascript hack that forces the websites to use devicePixelRatio 1.5 . This seems to trigger a bug when both javascript files are running in webview (webkit). I don't think it will be fixed as qt is going to use the blink engine in the future releases but let's see. As a quick and dirty workaround try to directly open a link with an article on tagesschau.de and let it finish loading. Then click on the banner on the top to go to tagesschau.de . This should not trigger the webview webengine crash. I am searching for a better solution for tagesschau now but am not so optimistic. I hope you did not find any other page with this issue.
@llelectronics Guess you're right. It's the only site with this behaviour until now and yes, it's a (laggy) mess. That's why i use it for stressing browsers. (: Thank you for the answer and keep up the good work!
Mmmmmh, it's very dirty but we can avoid the execution of the devicepixelratiohack in that specific website :)
I agree with @llelectronics: QtWebKit bugs remains there because it is replaced by Qt WebEngine (Blink based), so we can try to "patch" it with hacks and javascript injections and waiting for Qt 5.4
I tested with this site in particular and my latest commit makes it work without a freeze or webview hang. Though on all sites the devicePixelRatio will be set later (basically when all images and javscript code is run). So it can be definitely seen that the site during loading time will be a lot smaller but once loaded will change the DPR. See: https://github.com/llelectronics/webcat/commit/c19f08cb178ae5aa46342a98a32eced445d61ee5
I have noticed this "undocumented" parameter that it seems to affect the web page scaling.
I have tested in this way:
experimental.customLayoutWidth: Screen.width / 1.5
This was my initial hack for devicePixel Ratio in webcat. Though I deactivated it as it showed side effects on some sites that did not render properly anymore. See: https://github.com/llelectronics/webcat/blob/master/qml/pages/FirstPage.qml#L301
It seems to work good!
experimental.customLayoutWidth: Screen.width / 1.5
experimental.overview: true // What is overview?!?
I will make some extended tests
_EDIT_ Something keeps rescaling the website during scolling, I will investigate further
Are you testing this together with the other devicePixelRatio hack ? Then it might actually work. Need also do some testing. I think some desktop only sites had trouble or google mobile sites. I am not sure anymore as it is really some time ago I tested this. And no I don't know what overview is.
No it's disabled. Websites looks like with Pixel Ratio Hack enabled (without the "double rescale" effect)
Desktop website seems to ignore that setting (they use preferredContentWidth)
A few sites that show problems.
Geraspora (or any diaspora site I guess). Initially it loads correctly but as soon as you scroll around it changes its size to ultra small again with a large white space on the right side:
There are also some forums that have problems.
The "scrolling resize" seems to be related to experimental.preferredMinimumContentsWidth
I have made a "quick and dirty" test by doing:
experimental.preferredMinimumContentsWidth: Screen.width / 1.5
experimental.customLayoutWidth: Screen.width / 1.5
EDIT No, epic fail again, I have deleted the cache, is still there :(
Ok, conclusion:
I will keep customLayoutWidth property set along with PixelRatioHack.js so the "double resize" effect will be hidden to the user :)
Some info.
experimental.customLayoutWidth: https://github.com/mer-packages/qtwebkit5/pull/5 experimental.overview: https://github.com/mer-packages/qtwebkit5/pull/9
Small Update. I created a fork of qtwebkit from merproject and added the device pixel ratio patches from Ubuntu. The result is catastrophic at least on the tablet it makes the browser unusable. See this video demo: https://www.youtube.com/watch?v=3uQaag_ddrA The main reason for the slowness is the missing accelerated surface support for the Wayland backend which causes laggy scrolling aswell as (I assume) the tiled backend store to need up to 1 minute to refresh new parts of the site. (Gnome and GTK Devs are now working on some solution for Wayland support but it isn't merged and I am not sure if it is able to be used in general) The code is here: https://github.com/llelectronics/lls-qtwebkit [The code includes also some other important memory leak fixes and so on that reduce memory usage and loading times aswell]
How did you managed to compile QtWebKit and test it in Webcat?!? I have tried lots of times but it was too slow to compile inside MerSDK's VM.
About your issue: It can be a regression of "new" commits? Or the WebView isn't hardware accelerated even in "stock" QtWebKit?
Yeah compiling in MerSDKs VM would take several years I guess :P So I followed this tutorial to create a chroot copy of the MerSDKs build-engine: http://katastrophos.net/andre/blog/2014/03/29/running-sailfishos-build-engine-outside-virtualbox-vm/
With this I was able to use all 6 cores of my machine and the full amount of memory to compile qtwebkit.
The issue after DPR itself is nothing that comes from one of the commits. I also talked with one qtwebkit developer (the one that basically restarted the project and adds new patches and code to it [though only WebKit1 for now]) and the basic problem is the missing backend for accelerated surface on wayland. So the UI of WebKit2 can be hardware accelerated but the rendering engine itself isn't. And as the UIProcess and the WebProcess (rendering engine) need to share memory for having smooth scrolling and tiled backing store refresh (just like on X11 with glx and a normal Gnu/Linux desktop) it isn't an easy task to implement for Wayland. The GTK guys basically implement the accelerated surface thing as wayland compositor itself I think. At least thats what I understood so far. Btw. I also compiled html5 audio+video capable builds. Though only the gstreamer 1 backend works.(qtmultimedia leads to failed builds during compiling) The biggest issue here is that the droid backend used by SailfishOS 2.x nowadays for H264 support for videos isn't compatible. At least I wasn't able to playback any h264 videos with it. Only OGG Theora HTML5 video was supported. Audio wise everything was supported insterestingly enough. Though one misterious issue on all no matter audio or video is that all are automatically set to mute. Some players offer an unmute option others simply don't and the volume keys itself aren't able to unmute the audio so you can watch video (also choppy if 720p or fullscreen) but don't get audio mostly. Also memory usage rises and I head several occasions where even with Webcat being the only application open and only one site loaded the OOM killer kicked in and that was me testing it on the tablet with 2 GB of RAM. WebView Crashes also occur ever now and then on some sites. Though thanks to other patches reloading the page brings it back (so it doesn't crash the browser completely) I was able to get h264 and webm working by moving the droid gstreamer backend away and adding a custom gstreamer-libav backend with all codecs compiled in. Though that would have some nasty bugs in the browsers gstreamer html5 player where it sometimes cripples the whole graphics on screen besides the video itself (text becomes unreadable and all UI elements look like the graphics card broke). And on screen rotation the video freezes.
Mmmh, if I remember correctly the (unfinished) chromium backend, QuickSilver used some patches in order to use the hardware acceleration in Wayland.
QuickSilver (Next branch): https://github.com/tworaz/quicksilver/tree/next Ozone on Wayland: https://github.com/tworaz/ozone-wayland OzoneQt: https://github.com/tworaz/ozone_qt Nice patch: https://github.com/tworaz/ozone_qt/blob/master/patches/qtwayland/0001-Make-it-possible-to-obtain-wl_egl_window-handle-from.patch (should be available out of the box in Sailfish >= 1.1.9.x)
Thanks to all involved. I've just recently made a WebView app for Tasmota (web ui interface for Sonoff Basic) and upon opening the app, the page contents were very small, not what I wanted. I tried scale and other tricks, but to no avail, then stumbled across this page. Adding "import QtWebkit.experimental 1.0" and "experimental.preferredMinimumContentsWidth" now gives my webview app a much nice look/feel and is now proportional to my Jolla1 screen.
