Il giorno gio, 27/03/2008 alle 01.19 +0100, Denis Oliver Kropp ha scritto: > Claudio Ciccani wrote: > > Some weeks ago I announced to the mailing list that I was working on a > > DirectFB based OpenVG implementation (i.e. DirectVG). > > Well, now it's time to prove that it was not a bullshit and that I made > > some progresses in the meanwhile. > > Yep ;) > > > Below is a screenshot of the well known tiger sample rendered by DirectVG: > > http://img160.imagevenue.com/img.php?image=63785_DirectVG3_Tiger_122_898lo.jpg > > It looks pretty good already! Where's the code :)
Will upload soon. > > > As you can see, there is still some work to do on the strokes > > (stroke styles are completely missing and so is line scaling), but the hard > > part is done. > > > > Regarding the performance, well... at this stage it simply sucks! > > > > Testing Hardware: ATI Radeon 9250 > > Testing Resolution: 612x622 > > Runtime Speed: ~ 11 fps > > Not too bad. CPU bottleneck still, I guess... > > How many thousand(?) calls to the IDirectFBSurface API is this doing? > > Or do you use dfb_state_*() and dfb_gfxcard_*() which I am at the moment in > the public Water version? I'm using the current standard API (no internal calls). > > > I'm thinking about a more open intermediate solution that might keep a few > convenience functions for blitting > and filling and should replace all dfb_gfxcard_fill/draw/state*() cruft, > keeping the dfb_state_*() functions, > but allowing acquisition for more than a few driver calls. For example > changing color etc. does not need a > complete release/acquire including all locks. Just call the driver's > SetState() and Fill/Draw/Blit() as they > are needed, during one acquisition, until hitting a software fallback at > least. > > > Please check your system load and/or test with single application core, which > does not have the system call > impact per (macro) graphics operation. BTW, Fusion could eliminate most of > the system call overhead like futexes do. > I think that actually the lack of performance is more related to the frequent change of the destination surface than to the "locking" overhead. For example, the code always assume concave/intersecting polygons and this actually requires rendering to a temporary surface (this is because, to save a lot of floating-point math, I implement EvenOdd filling by XORing instead of tesselating the path into convex polygons). -- Claudio Ciccani [EMAIL PROTECTED] [EMAIL PROTECTED] http://directfb.org _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
