explore alternative render techniques
cztomsik opened this issue · 6 comments
there are some issues with webrender, mostly the complexity which is implied by the fact that the whole thing was designed for a web browser, it has a lot of deps & doesn't support gles2/webgl
pathfinder might be an alternative (doesn't support gles2 but at least they're planning webgl version) however then we would need to deal with:
- images (not sure how to mix paths with texture)
- shadows (in correct order)
- clip images in border-radius?
- scrolling
- hit testing
another very interesting approach is what makepad is doing but that has a bit easier task because of layout which is part of the rendering and I think it's also missing shadows, clipping (overflow: hidden), and similar things I really want to support
from the talk I've found, there's some shader library which might be useful (at least for inspiration)
maybe doing some simplified webrender might be possible too
relates to #110 #103
another lib (requires gl3) https://github.com/intel/fastuidraw
I'm going try something myself, here's a repo https://github.com/cztomsik/new-hope
Hi @cztomsik ,
Awesome project you've got going here.
This issue stirred up my curiosity. I thought webrenderer provided a higher level API than, say skia or pathfinder, and performed a lot of work under the cover (culling, compositing, animating). I'm curious why would you want to go back to lower-level primitives and have to deal with all of this stuff yourself?
Being aware of the general requirements of UIs, but free from actual DOM or CSS implementations, webrenderer looked like the ideal candidate for a project like this.
Also, (sorry for drifting off-topic here) why were you using pango? Wasn't webrenderer supposed to handle text rendering?
I would highly appreciate if you could help shed light on the obscure arcanes of webrenderer, as I am myself a total noob in this domain.
Thanks.
Hey, thank you for your kind words and also for your interest :)
I've written about some of the reasons in a blog post but you're right webrender does a lot and I'm basically throwing away a lot of effort from people smarter (and definitely more experienced in that area) than me.
In short, I think it's not that hard and I think I can do it with less memory and CPU overhead (I want to use it on raspi 3 A+ and that is very, very slow and webrender does not support it anyway). I have no numbers but I really think webrender would be too slow there.
For example with webrender you need to build the whole scene every frame, then it is serialized & sent to a different thread just to be deserialized again and the frame can be rebuilt to a different structure(s) and only then it starts to actually prepare some data for GPU. All of this is killing raspi. I want to do it in a classic, stateful way so that if there's little change, it should do little work and to actually be as direct as possible.
I'm also not re-creating a browser here, it is intentionally going to miss some of the web legacy which webrender has to support in order to be useful for firefox and it's also kinda expected for a browser to have some overhead. Webrender is fast but they are not aiming for low-overhead, they are optimizing for the worst cases and performance cliffs.
About pango, all what webrender does is that is can rasterize glyphs to a glyph atlas using freetype (or pathfinder in future). All of the actual text layout is left to gecko and so I had to solve it somehow. At first, pango looked like a quick win but unfortunately, pango leading is not directly translatable to the line-height and so I had to compute glyph positions myself and then I've lost all of the international layouting and so I've just decided to drop it for now and replace it with something else in the future.
If you want to hear anything more about webrender (and I will be able to answer it), you can reach me in our discord channel or just tweet me.
Thanks for your answer.
I read the blog post and I think it makes total sense when you say that relying on a large oss library you don't fully understand can add bugs, development time and make things harder. Especially if it's to realize a year later that this lib was doing exactly what you thought it was.
This definitely answered my question.
I still have a question regarding how you plan to handle text, but I'll take it to a different issue as it is not closely related to this issue.
still not 100% done but enough to close this