This is quite interesting, but I have a bunch of questions regarding this. What makes the 2D drawing code WebKit-specific? Is it possible to package up the rendering code into a self-contained standalone library?
Regarding text, do you have a strategy for instancing geometry or using a glyph atlas? Did you implement the Loop Blinn path algorithm? Did you experiment with attempting to re-order independent drawing commands to achieve high GPU occupancy? Are you measuring power use in addition to time-based performance? It sounds like OpenGL is doing the drawing itself; I would imagine there are many many draw calls per webpage. Does the OpenGL driver introduce significant overhead? Are you thinking of publishing your findings? I would be very interested to read about design decisions you encountered along the way. Thanks, Myles > On Nov 13, 2014, at 12:40 AM, Benjamin Poulain <benja...@webkit.org> wrote: > > How does TyGL perform compared to the other rasterizers? > > What benchmarks do you use to guide the performance work? > >> On 11/12/14, 11:12 PM, Zoltan Herczeg wrote: >> Hi All, >> >> We are proud to announce the TyGL port (link: >> http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced >> as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on >> embedded systems. The engine is purely GPU based. It has been developed on >> and tested against ARM-Mali GPU, but it is designed to work on any GPU >> conforming to OpenGL ES 2.0 or higher. >> >> The GPU involvement on future graphics is inevitable considering the pixel >> growth rate of displays, but harnessing the GPU power requires a different >> approach than CPU-based optimizations. 2D graphics is traditionally >> software-based however, and 2D APIs are interfaces to these CPU-based >> algorithms. WebKit GraphicsContext API is no different, so the key >> challenge of our project was and is producing the expected output in a GPU >> friendly way. >> >> Key features: >> >> Batching pipeline: >> >> GPU provides the highest performance when a large number of triangles are >> drawn with a single draw command without any OpenGL state changes. The >> GraphicsContext API in WebKit provides draw operations for single shapes >> however, which can result frequent state changes if implemented naively. >> TyGL was designed to group these commands to reduce the number of draw >> calls. >> >> Automatic shader generator: >> >> TyGL can generate complex shaders from multiple shader fragments, which >> allows efficient batching but it also takes care to make them fit into the >> shader cache of the GPU. >> >> Trapezoid based path rendering: >> >> TyGL uses trapezoid-based tesselation of shapes and the GPU renders them >> with high anti-aliasing quality. We are continuously improving this part >> of the engine and look forward to make use of new GPU capabilities (like >> Pixel Local Storage) to squeeze more performance out of it. >> >> No software fallback: >> >> The whole engine is optimized for GPU without legacy software fallback. >> Hence we don't need to sacrifice optimizations for compatibility. There >> are enough software based 2D libraries which can be used when GPU is not >> available. >> >> TyGL is already capable of rendering many web-sites correctly, but some >> features have not been implemented yet. We continue this work and we are >> open to contributions from the community. Contact to us if you want more >> information about the project. >> >> Regards, >> U-Szeged's web browser team. >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev