@vigneshlin Not quite. It will be a Blink rendering engine in most cases on recent devices.
But Turbo mode in 'Opera Mini' loads the default WebView that comes with your Android OS.
While turbo in 'Opera for Android' uses the full custom Opera Blink rendering engine. Generally that means Turbo mode in 'Opera Mini' is slightly less capable with eventual feature restrictions and not the evergreen/edge version of 'Opera for Android'.
Posts made by hexalys
-
RE: Opera Mini 10 beta 1 for AndroidOpera Mini
-
RE: Opera Mini 10 beta 1 for AndroidOpera Mini
A couple things I noticed:
1 - Can't force reload a page yet. Will need a forced proxy refresh.
2 - Text Size has no effect yet. In my case, it uses the Amazon WebView FireOS font size settings as default font size. (be aware of that)
-
RE: Opera Mini Screen Size, DPR and Viewport InaccuraciesOpera Mini
Found the answer to this from @andreasbovens. I guess we have no choice to deal with Opera Mini doing its own thing.
-
RE: ViewportOpera Mini
It does but their calculation of the
viewport-width
is very inconsistent (at least on Android). Hence the viewport is often not matching the device. -
Opera Mini Screen Size, DPR and Viewport InaccuraciesOpera Mini
Opera Mini for Android seem to have a major issue with the correct determination of the 'viewport-width' size.
I have tested Opera Mini for over a year now, and whether on an SDK emulator or actual device, it's always incorrect.Here is a use case on a Fire HD Tablet (Amazon Kindle Fire HD 7" 4th Gen):
The physical screen is 1280x800 1.5 DPR. Which at a Portrait Orientation should result in a layout Screen Size of 534 x 854 px.
Hover Opera Mini for Android (both 8 and 9 beta) returns a viewport-width of 381px with a DPR of 2.1,screen.width
of 381px andwindow.outerwidth
of 800px.So the math 800/2.1 is correct, but where does it pull a
docElem.clientWidth
of 381px from the device data? I don't see how you get to that result.