Render problem

[SCratORS]

@Doctoror Can you help me somehow?
If you set the screen resolution to 240*320, you can notice artifacts of the display of objects. It is clearly visible on the "Dandelions". I understand what this is about, but I can't find a solution to how it can be improved.

This problem occurs in the function of converting vector graphics to a raster texture here
When the vector graphics line is very thin and the resolution of the bitmap texture is not enough.
It should be drawn based on the pixels of the outer contour of the line. But it draws based on the internal pixels of the contour.

[Doctoror]

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

[SCratORS]

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.

[Doctoror]

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

[SCratORS]

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

[Doctoror]

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

[SCratORS]

ok

[Doctoror]

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.

[SCratORS]

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.

[Doctoror]

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.

[SCratORS]

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

[Doctoror]

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.

[SCratORS]

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.

[Doctoror]

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.

[Doctoror]

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

[SCratORS]

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

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