Claudio Ciccani wrote: > 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.
Great. I'm extremely busy with Water at the moment, time for plugging in some modules for "translation" of elements or "interpretation" of unsupported rendering (attributes) :) >>> 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). With Linux Kernel Fusion? >> 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" Should destination surface changes cause so much delay? Please use "time tiger" :) > 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). Yes, that makes sense :) -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
