DPI/screen scaling when using OpenGL

Android
1

I’m porting one of our apps to Android - it already runs fine on iOS and desktop formats.

The app runs only in landscape and is hardcoded to 1024 x 768. I’m using setGlobalScaleFactor to account for different screen DPIs.

If I don’t use OpenGL, then the app scales perfectly to the screen but the graphics are sluggish.

If I attach an OpenGLContext to my MainComponent then the app appears squashed vertically but the touch sense acts as if the app has been rendered correctly, i.e. tapping slightly below where the button appears gets registered as a button press. The graphics are very responsive though :wink:

Is there something I need to do to get the OpenGL version to render correctly?

2

This may be related to a bug that I reported:

My best recommendation is using the SoundRadix branch, which has fixes for OpenGLContext scaling.

One thing we had to do as well: Don’t attach OpenGLContext to the top level component. Create a Component to hold your OpenGL Component, and attach the context to the OpenGL Component only. Between the SoundRadix fixes and that, we were able to fix our OpenGL issues.

2 Likes
3

Thanks for your reply - that’s the exact problem!

Is this only an issue for Juce 4.2? If so I can roll back to an earlier version.

4

Unfortunately, no. It appears that this problem has been happening for a while. The SR branch closely mirrors the main JUCE branch and doesn’t require additional changes to your codebase (i.e. no bonus virtual functions that need defined anywhere)

It can be found at https://github.com/soundradix/JUCE/commits/master

1 Like
5

Excellent, thanks! I’ll give that a try tomorrow and report back.

6

Unfortunately this doesn’t seem to fix the problem on Android.

Using the SR fork, I have tried various combinations of attaching the OpenGLContext to parent and child components, but the scaling is always wrong.

7

I’m trying to fix this but I am (once more) struggling to get the Android Studio debugger working. However, I think I’ve narrowed down the problem pretty far already.

1 Like
8

Sorry this seems like a hard nut to crack. It’s actually a bug which occurs on all platforms except OS X. If fixed a bunch of other bugs along the way but it still not working properly. Jules will have a go at this today.

9

Thanks for the update Fabian. I did notice that it works fine on OS X, as I did some testing yesterday.

Fingers crossed for a solution :slight_smile:

10

Has there been any progress on this bug?

11

Sorry, Fabian’s away this week and I’ve been super-busy… Not forgotten though, we’ll nail it soon!

1 Like
12

Any progress to report on this issue?

13

We’re still working on this issue. It requires some re-thinking of a few functions in ComponentPeer which will ultimately break backward compatibility with code directly using the ComponentPeer and global scaling factors. We need to think about how to do the changes without breaking too much.

Sorry this bug turned out to be much more involved than expected.

14

Hi Fabian,

Thanks for the update. Are there any possible workarounds that we can try here?

Cheers,
Mark

15

Well don’t use setGlobalScaleFactor and instead edit the scaling factor code here. Sorry about the unclean workaround.

1 Like
16

Hi Fabian,

Thanks for the tip - I’ve now got the screen scaling correctly when using OpenGL.

One question, why is the ratio calculation in findDisplays d.dpi/150? Should it not be d.dpi/160? According to the Android docs, 1 density independent pixel corresponds to a physical pixel at 160 DPI. I’m targeting the Samsung Galaxy Tab A which has a DPI of 160, and it does not render correctly unless the ratio is 1:1.
With d.dpi/150 the GUI is rendered too large for the screen.