<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 02/08/18 08:27, Peter Bennett wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e16d8079-247a-5787-06c8-8d932d22c926@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 08/01/2018 05:17 PM, Peter Bennett
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a2a0796c-02d9-7727-5b6f-e68f18897fc2@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 07/30/2018 11:17 PM, Mark Spieth
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0542bb80-dc96-a76e-a9c0-c97a04980c8e@digivation.com.au">
<br>
On 31/07/18 08:52, Peter Bennett wrote: <br>
<blockquote type="cite"> <br>
<br>
On 07/29/2018 06:58 PM, Mark Spieth wrote: <br>
<blockquote type="cite"> <br>
On 30 July 2018 08:29:31 GMT+10:00, Peter Bennett <a
class="moz-txt-link-rfc2396E"
href="mailto:pb.mythtv@gmail.com" moz-do-not-send="true"><pb.mythtv@gmail.com></a>
wrote: <br>
<blockquote type="cite"> <br>
On 07/29/2018 06:14 PM, Mark Spieth wrote: <br>
<blockquote type="cite">Is this also with video playback
or UI only? <br>
</blockquote>
It is both. In the Setup->Appearance I tried changing
the GUI size to <br>
1280x720. That should have used one third of the width
and height, but <br>
actually used two thirds of the width and height. <br>
<blockquote type="cite">Is it different with media codec
vs GLES? <br>
<br>
</blockquote>
No - media codec is also using OpenGL for output, the
same as used by <br>
software decoding. It may be different with a surface
but there is no <br>
code to use a surface at this time. <br>
<blockquote type="cite">CPU definitely takes a hit for a
4K screen though. <br>
Will do some research on this. <br>
<br>
</blockquote>
</blockquote>
Smells like a qt or platform gl problem. Need to check qt
source for 1920 restrictions. <br>
<br>
<br>
</blockquote>
FWIW 4K video works fine with Qt on Linux. Also I tested the
4K video with Kodi on Shield and it is playing with the full
4K resolution on my monitor, so it is possible to do it. I
did scan carefully through the Kodi manifest but I could
find nothing that might help me. <br>
<br>
</blockquote>
Here is something to look at. <br>
in qt source
qtbase/src/plugins/platforms/android/androidjnimain.cpp <br>
<br>
there are 2 functions <br>
createSurface and setSurfaceGeometry. This is the lowest level
before android and applies to qt's gl surface it allocates at
start. <br>
instrument with some __android_log_print to see what height
and width are being used. These will appear in logcat. <br>
Make changes and then makelibs.sh without clean. Wont take as
long as clean and you dont need to export any diffs either. <br>
Changes are preserved. since git is used for baselining you
can git diff to get your patches too. <br>
<br>
Note this is the file that launches main() in mythtv. see
startapplication which launches a thread which then runs
main(). This is called from the java initial code (some in qt
and 1 overridden in our android_package_source tree. <br>
<br>
Not sure when I can test this but may give you some hints as
to where the 4k is going. <br>
<br>
All parts of our android app is using gl for rendering. <br>
You can also go for gdb and break in these functions if you
are extra adventurous. <br>
<br>
HTH <br>
Mark <br>
</blockquote>
<br>
This is what I get logged<br>
<br>
androidjnimain.cpp setDisplayMetrics wP=1920 hP=1080 dWP=1920
dHP=1080 xdpi=213.000000 ydpi=213.000000 sD=2.000000 d=2.000000<br>
qandroidplatformintegration.cpp setDefaultDisplayMetrics gw=1920
gh=1080 sw=229 sh=129 scrW=1920 scrH=1080<br>
androidjnimain.cpp setSurfaceGeometry x=0 y=0 w=1920 h=1080<br>
<br>
setDisplayMetrics parameters logged are<br>
widthPixels, heightPixels,<br>
desktopWidthPixels, desktopHeightPixels,<br>
xdpi, ydpi,<br>
scaledDensity, density);<br>
<br>
Those last two parameters of setDisplayMetrics look like a
possible cause<br>
scaledDensity=2 and density=2. Documentation says scaledDensity
is for fonts and density is logical density.<br>
<br>
QtLayout.onSizeChanged (java)<br>
calls android.view.Display.getMetrics()<br>
calls QtNative.setApplicationDisplayMetrics()<br>
calls setDisplayMetrics (c++)<br>
<br>
<br>
<i>public void getMetrics (DisplayMetrics outMetrics)</i><i><br>
</i><i><br>
</i><i>Gets display metrics that describe the size and density
of this display. The size returned by this method does not
necessarily represent the actual raw size (native resolution)
of the display.</i><i><br>
</i><i>2.</i><i><b> It may be scaled to provide compatibility
with older applications that were originally designed for
smaller displays.<br>
</b></i>How do we explain to android this is not an older
application like that? Will each android device do its own thing
here?<br>
<br>
<i>DisplayMetrics.density</i><i><br>
</i><i>The logical density of the display. This is a scaling
factor for the Density Independent Pixel unit, where one DIP
is one pixel on an approximately 160 dpi screen (for example a
240x320, 1.5"x2" screen), providing the baseline of the
system's display. Thus on a 160dpi screen this density value
will be 1; on a 120 dpi screen it would be .75; etc. </i><i><br>
</i><br>
Maybe we should use getRealMetrics instead of getMetrics I can
try that.<br>
<br>
Otherwise multiply screen height and width by density.<br>
<br>
Either way involves changing some QT code ???<br>
<br>
Peter<br>
</blockquote>
<br>
No solution in sight - with the display physically at 1920x1080 or
3840x2160 the metrics are the same. Also using getRealMetrics
returns the same in both 1920 and 3840 resolution cases..<br>
<br>
All 4 cases return the same values - <br>
androidjnimain.cpp setDisplayMetrics wP=1920 hP=1080 dWP=1920
dHP=1080 xdpi=213.000000 ydpi=213.000000 sD=2.000000 d=2.000000<br>
<br>
</blockquote>
Another thing to try<br>
<br>
in qt src<br>
qtbase/src/android/jar/src/org/qtproject/qt5/android<br>
change all getMetrics calls to getRealMetrics in the java files.<br>
<br>
It may be possible to copy these to android-package-source tree but
not sure as they are in the jar directory not the java directory.
Should work though and then we can modify them as required without
patching qt. It would mean a diff/merge on updating qt though just
in case these change.<br>
<br>
The optimal change is to check for PAI or try except get realmetrics
and then use getmetrics as a fallback. However since the APIs we are
targeting, this is probably not necessary as getRealMetrics should
be available always.<br>
<br>
Mark<br>
<br>
<br>
</body>
</html>