Render problem about everchanging HOT 21 OPEN

I believe this is happening because we convert vector graphics into a Bitmap and then scale the Bitmap.
This should be fixable with multisampling:
http://www.saschahlusiak.de/2012/10/opengl-antialiasing-in-android-with-transparent-textures/

I tried enabling multisampling but it is limited on emulators, and I don't have 240x320 physical device to verify.
Emulators only supports multisampling of 2 and it did not look like it changed anything.

I found out that emulaors might not even have multisampling working at all, even when you open Emulator menus
https://www.reddit.com/r/AndroidStudio/comments/qh3jf6/avd_resolution_antialiasing_problem/?rdt=64969

from everchanging.

It is possible that it is a matter of multisampling. But it doesn't seem like it. You can use a larger resolution. for example, 540*960 effect is also observed. I'm not sure exactly, but probably BlueStack (as an emulator created for android games on PC) supports multisampling, but the effect persists.

from everchanging.

But have you enabled multi sampling in the egl config chooser before retesting on blue stack?

from everchanging.

I can't find any such settings there. there is only software, hardware, opengl or vulkan rendering

from everchanging.

This has to be enabled in app. I will send you a branch to test later, in a few hours, when I have time.

from everchanging.

ok

from everchanging.

You can check with multisampling on this branch
https://github.com/Doctoror/Everchanging/tree/multisampling

Play around, see if it improves anything. If not then no need to merge.
Note that higher value usually reduces performance.

I copied EGLConfigChoosers from my other repo hence the licenses and package names.
The logic behind the choosers is that a config chooser can fail if unsupported config is attempted to be chosen.
If multisampling with value 4 is not supported 2 will be attempted.
Nvidia multisampling will be attempted if default multisampling fails.
The config with null will be passed if all other configs failed.
Null config means that the platform requests no requirements.

from everchanging.

I got this in the logcat:

GL com.scrat.everchanging ViewportNeedFlush 0
EGLConfig chosen: [12324, 8, 12323, 8, 12322, 8, 12325, 0, 12338, 1, 12337, 4, 12352, 4, 12344]

It did not have any visible effect.

In principle, this is expected.
The problem lies precisely in the function of generating textures from SVG graphics. With insufficient DPI, the texture itself is already obtained with artifacts, and there are no OpenGL calls there yet.

from everchanging.

I thought the texture is generated with intrinsic width, and then scaled down by matrix transform 🤔

The texture itself isn't in vector graphics then, I suppose.

from everchanging.

A texture is being generated from an XML Drawable - Canvas Picture. Using the drawable.draw(canvas) method here

from everchanging.

Yes, I saw that. What I mean is that I don't see any resizing occur there. That's why I don't get it why it looks scaled down.

BTW I see some problems with that code that unnecessarily loads bitmap twice and also uses id resolution based on names. It doesn't affect the scaling issue, of course, but that's something that can be improved. I will open a PR for that later.

from everchanging.

The size problem is that the xml vector accepts dp (dip pixel) as units of length. because of this, the lower the DPI of the display, the smaller the texture itself at the output.

Raster graphics do not have such a thing as dp, therefore, textures of different sizes were obtained on different DPI displays in relation to the visible drawing area. to bring this to a uniform size, for raster graphics I call "dipToPixel" to get the scale factor.

from everchanging.

The size problem is that the xml vector accepts dp

Not necessarily. You can do this:

<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:width="180.9px"
    android:height="208.05px"
    ...

But this would not be correct to change. You want smaller output on smaller density devices and bigger output on bigger density devices. That's why dp is useful. But I see that the loaded images are too big anyway.

The problem is that, for example, this is the original size of the dandelion on 320x480.
And in OpenGL it will be scaled down to draw by transforms and viewports, so that's why we see artifacts.

from everchanging.

I think multisampling doesn't work because we don't use framebuffers.
I don't know how to use them. I tried something here but couldn't make it work.

Commit:
9ab3fd9

Branch:
https://github.com/Doctoror/Everchanging/tree/framebuffers

from everchanging.

But I see that the loaded images are too big anyway.

Yes, the original had such dimensions. I didn't invent anything here myself.

from everchanging.

If in the texture manager, where the texture of the vector object is generated, add this:

drawable.setBounds(0, 0, canvas.getWidth(), canvas.getHeight());
drawable.draw(canvas);
drawable.setBounds(8, 0, canvas.getWidth()+8, canvas.getHeight());
drawable.draw(canvas);
drawable.setBounds(16, 0, canvas.getWidth()+16, canvas.getHeight());
drawable.draw(canvas);
drawable.setBounds(16, 8, canvas.getWidth()+16, canvas.getHeight()+8);
drawable.draw(canvas);
drawable.setBounds(16, 16, canvas.getWidth()+16, canvas.getHeight()+16);
drawable.draw(canvas);
drawable.setBounds(8, 16, canvas.getWidth()+8, canvas.getHeight()+16);
drawable.draw(canvas);
drawable.setBounds(0, 16, canvas.getWidth(), canvas.getHeight()+16);
drawable.draw(canvas);
drawable.setBounds(0, 8, canvas.getWidth(), canvas.getHeight()+8);
drawable.draw(canvas);

Of course, this helps to partially solve the problem, but this is a very bad option in my opinion.

from everchanging.

Yes, this doesn't seem like a good option. I think it's okay to have a bigger texture scaled down, we just need to make multi sampling work. It works with textures only with OpenGL ES 3.2. I'm not sure how to correctly request 3.2 and how to make frame buffers work.

In my config chooser I enable Open GL ES 2.0 which is wrong, I don't know how to request 3.2. Maybe just remove that line?

EGL10.EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT

Also, the framebuffers apparently don't work correctly.
If you have time, try to figure this out (the branch https://github.com/Doctoror/Everchanging/tree/framebuffers)

Once we have texture multi sampling and framebuffers I believe it should look fine.

from everchanging.

I figured out where to go. I will study the Framebuffer issue. It seems to be true.

from everchanging.

No matter how much I try, nothing normal happens. Either nothing at all, Or the same thing, Or the same thing but with glitches.

from everchanging.

I couldn't figure that as well. But I don't have much time anymore.

from everchanging.

Apparently we should leave it as it is for now

from everchanging.