Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad rendering method in the OpenGLES based demo. #45

Open
1 task
zwcloud opened this issue May 8, 2017 · 5 comments
Open
1 task

Bad rendering method in the OpenGLES based demo. #45

zwcloud opened this issue May 8, 2017 · 5 comments

Comments

@zwcloud
Copy link
Contributor

zwcloud commented May 8, 2017

From this, we can see each GlyphRun uses a drawcall and it harms performance badly when rendering a string containing many characters.

I think we should apply the offset when we fill the vertex buffer. I mean, bake the offset into vertex instead of offset every glyph in vertex shader, just like what I have done before in my original OpenGLES demo.

Update:
No, my soultion is incorrect partially. The mesh should only be moved after it is built. Otherwise we can not re-use the old mesh when the position of text is changed but its content and style remains the same. But I think the offset of each glyph should be applied to built vertices.


@prepare's note:

  • add VBO version for GLES glyph rendering
@prepare
Copy link
Member

prepare commented May 8, 2017

Thank you for your report, I will look at it.

Do you have the comparison results of method 1 and 2 ?
please let me know

@zwcloud
Copy link
Contributor Author

zwcloud commented May 8, 2017

Do you have the comparison results of method 1 and 2 ?

No. But I think you may have a look at this SO post. I should say it is common sense to reduce drawcalls.

@prepare
Copy link
Member

prepare commented May 8, 2017

at this time,
I think the performance problem in the 'demo' may come from ...
I load triangles mesh into GPU every time for every glyph.

(ref) ... Each time DrawModel is called, the index and vertex data are copied to OpenGL ES, and transferred to the graphics hardware. If the vertex data does not change between invocations, these unnecessary copies can impact performance. To avoid unnecessary copies, your app should store its vertex data in a vertex buffer object (VBO). Because OpenGL ES owns the vertex buffer object’s memory, it can store the buffer in memory that is more accessible to the graphics hardware, or pre-process the data into the preferred format for the graphics hardware.


solutions:

  1. use VBO, I will implement this later, (see https://github.com/prepare/PixelFarm-dev/issues/38).
  2. use Glyph texture, for general font. (use Triangles for very large font)
    see https://github.com/LayoutFarm/Typography/tree/master/Typography.MsdfGen

this is a sample of msdf texture font, fast and scalable!
msdf_test_03
pic 1: msdf texture font sample

subpix06
pic 2: subpixel font texture with GLES2

latest subpixel font texture rendering with GLES2 (PREVIEW) gives a very cripes look!
glyph_analysis_e_26

pic 3: Tahoma, 8 pt, (1) No AutoFit , (2) with AutoFit,
Tahoma, 10pt, (3) No AutoFit, (4) with AutoFit

gles2_html2

pic 4: render with OpenGLES2, Text is rendering with PixelFarm's MiniAgg+ the Typography.

@zwcloud
Copy link
Contributor Author

zwcloud commented May 8, 2017

load triangles mesh into GPU every time for every glyph

Yes. That should be avoided.

MSDF is a good way to render glyphs on any platforms. But personally, I prefer 3D-graphics-only method to render glyphs. Because pixels in a mobile screen are so small that anti-aliasing is no longer needed and it's quite easy to implement (just fill the line-segments and bezier curves). We may possibly find some way to improve the rendered result by adjusting it in the vertex or pixel shader in the future for desktop platforms.

My opinion may not be right. It's just my personal preference to try something new. 😄

@prepare
Copy link
Member

prepare commented May 25, 2017

Now, I'm tackling this with VBO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants