Having trashed comparasions to X11 I think I need to explain the current status of gdk-directfb and its drawing model.
First and foremost cairo support was added to the latest version of gdk-directfb. This presented a challenge during the port since initially only the cairo software fallbacks were supported. If you look in the code you will see that we end up with DSPF_ARGB visual format most of the time look in _gdk_visual_init. It should at least support falling back to the default pix format even it its not acclerated this is not true right now. So the first slowdown is we are in general blitting a ARGB surface. A lot of work has been done to accelerate the cairo backend so that it can use the native format but this is not 100% yet and is turned off by default. These sort of format conversion issues are common in the current code base. The reason is right now its faster to use a ARGB surface most of the time than to end up with the cairo code repeatedly creating temporary ARGB fallback surfaces and blitting. Supporting the current direct DirectFB rendering calls complicates the issue since it causes not only a temporary buffer to be created but forces us to copy the current buffer into the temporary before we can render since we don't know if a dfb routine was used between cairo calls. In my opinion the best solution is to make sure that cairo can always perform the fastest operation for rendering and prove it seldom uses the image fallback routines. Once this is true then we should do all drawing through the cairo api so that if it needs to create a temporary buffer all rendering can be redirected to this buffer until we flip it at the end of the repaint loop. Even better if we detect we need a temp buffer we should retain it and not allocate and free it all the the time the size of this buffer should be configurable. Because of these issues the current code base represent the best compromise for overall real world performance considering the constraints. At the end I explain my latest drawing model. Finally right now basically all the pieces are actually in place to allow you to optimize the code for a given platform with known hardware acceleration support. In the case that your driver supports a accelerated blit and the destination is RGB or even better acclerated ARGB blits then performance should be reasonable now but I've not even profiled this case. Having done the work on Cairo and Gdk for directfb I now think that the always buffered window model is too restrictive and have proposed a mor generic drawing model for directfb based on declaring the drawing ops for a window and executing a renderop list to draw the windows. Three days ago Denis promised me a reply in two days :) So my present proposal going forward is to move to this drawing model and I think you can see it solves all of the rendering problems and nicely allows the mixing of cairo and directfb rendering ops since both would result in the same draw list. The current buffered window would then be one way to draw a window. Inspiration for this model is from OSX and Evas Canvas by Rasterman. So if you want to understand the concept read the evas docs http://www.deepsky.com/~e/pages/htmlized/evas/ The proposal is basically to implement the evas paint model for directfb. Rasterman already wrote all the documentation for me :) _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
