Il giorno gio, 27/03/2008 alle 11.20 +0100, Denis Oliver Kropp ha scritto: > 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?
Yes. > > >> 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" :) At least for the R200, destination change is penalizing. Also consider that the usage of a temporary surface (call it accumulator) requires an additional blit (with blending enabled). > > > 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 :) > With a simple convexity test (check if there's only one polygon and if the given polygon is convex), it runs at 12 fps. -- 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
