>> - simple imperative GLES2 painter suited for Canvas 2D etc, lose all >> the poorly / unnecessary performing features of QPainter >> - QPainterV2 API, reduced QPaintEngine API >> - learn from Skia >> - improved API that discourages slow use cases
> > This is far outside my knowledge area, but i am very curious to know > what kind of things can be learned from skia. I know skia is the > render engine for chrome and that's all i know about it. The lines left above highlights the general problem... The QPainter API is very feature rich and opens up for a number of use patterns that are less than ideal for performance. I was not in the session, so some other points might have been raised there, but this topic has been raised before in the oslo graphics team. If we were to strip down the QPainter API into a useful but bare minimum, then we might as well go for an API that is well adopted by now, and the natural candidate for that would be the HTML Canvas2D API. Then again, we also know that in terms of hardware accelerated graphics, imperative APIs are not really the way to go. Typical 2D graphics drawing consists of many tiny bits and pieces here and there and the overhead of every draw call in the driver outweighs the benefit of using hardware accelerated APIs in the first place. This is why QPainter on OpenGL is better than QPainter on raster in only select usecases. Personally, I am convinced that scene graphs are the right way to accelerate graphics as it opens up for reordering and batching which in the end results in optimal use of the graphics driver and thus also the hardware. It might be better to spend the effort making convenience APIs for the scene graph rather than trying to reimplement skia with Qt API. cheers, Gunnar _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
