Quoting Jakob Uszkoreit: > Basically I have two questions: is there any reason besides the fact > that most gfx_drivers use MMIO that the gfx_driver probing code is > disabled when not running with the framebuffer system module? I'm > asking because it might be reasonable for us to implement a > gfx_driver to optimize drawing on our platform without using a > framebuffer device.
The only reason is that no other system module enabled hardware acceleration so far. We might add system module capabilities to check if drivers should be probed. > The second question originates from the fact that we measured that > our environment only spends less than one percent of the time in > the drawing code of the software renderer and for example video decoding > on the cpu does not receive any performance hit while our UI redraw > framerates drop from 14 to 3 fps when we start drawing more complex > stuff... What would you think might be the reason(s) for this behaviour? You can run two example programs: df_dok and df_flip. The first one will most probably just render into system memory without an update to the screen. The latter one will measure the flipping performance and thus measure the overhead caused by the system's screen update, which might be the problem. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
