Claudio Ciccani wrote: > Il giorno ven, 15/02/2008 alle 00.00 +0100, Denis Oliver Kropp ha > scritto: >> [EMAIL PROTECTED] wrote: >>> New commits: >>> http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=93d6dc2d2fd5dad1fe84d9829c6f9c08c6c7fecb >>> commit 93d6dc2d2fd5dad1fe84d9829c6f9c08c6c7fecb >>> Author: Claudio Ciccani <[EMAIL PROTECTED]> >>> Date: Thu Feb 14 18:40:16 2008 +0100 >>> >>> Ported radeonfb patch to linux-2.6.22. >>> >>> patches/radeonfb-r300fix-2.6.22.patch.bz2 | Bin >>> 1 files changed, 0 insertions(+), 0 deletions(-) >>> >>> http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=9eba76a734d6937932c11a764a1c215999d93848 >>> commit 9eba76a734d6937932c11a764a1c215999d93848 >>> Author: Claudio Ciccani <[EMAIL PROTECTED]> >>> Date: Thu Feb 14 18:38:45 2008 +0100 >>> >>> RADEON: Implemented affine transformation (all cards) and source >>> masking (R100/R200 only). >>> Switched to version 1.1.2. >> >> :) :-p :) :-p :) :-p :) :-p AND THE PARTY ROCKS ON :-D :) :-D :) :-D :) :-D >> :) >> >> >> Not far til we have Cairo-DirectFB more functional, even without >> using TextureTriangles() or requiring a (real) 3D core... >> >> Do we need FillTrapezoid() and/or BlitTrapezoid()? > > I was just going to propose FillTrapezoid(); with this function, and > antialiasing enabled, you can fill oval shapes.
Ok, but Quadrangle would also cover this :) > We also need SetReadBuffer/SetWriteBuffer(), to avoid flipping the > surface when you need to change the target buffer. That's easy, just modifying the state members that are there since the new surface core came :) >> If so, I'd like to propose FillQuadrangles() instead :) > > What's the difference? Only 4 vertices instead of a variable amount? A trapezoid is a special quadrangle, and has 4 vertices as well, but restricted to same y coordinates for two pairs of them. >> What else? Maybe we can start to forge the new render interface >> or see how far we can get with the current model. It seems there's >> still a lot of room for surprises, things I never thought of being >> added, or even things I thought of never being added. For example >> indexed formats, bitmap fonts, or even YUV... our video layer was >> RGB24 :-) >> >> >> Anyhow, let's get everyone involved in DirectFB 2.0: > > For the 2.0 I'd like to remove some less used formats (DSPF_ARGB6666, > DSPF_ARGB1666 for example) to recover a bit of efficiency and add more I was also wondering why these were used when they're not packed anyhow. What's the advantage over ARGB? No shift in hardware? > useful formats (Y8, ALUT88, Planar YUV 4:4:2 and 4:4:4). Yeah, Y8 could be used to mask all three RGB channels only (same source alpha). Hope you meant 4:2:2 :) > We could also drop TextureTriangles() since this function will never > have a software fallback and, however, no one is going to use it > (generally you use OpenGL if you need to work in 3D). Really? Before we've done the GL (ES) integration, nobody can use OpenGL with DirectFB to render a 3D enhanced UI (maybe on an STB), in which case the method is great if your driver supports it. You don't have to care about other drivers. But for the final 2.0 you're right and it's really obsolete then :) -- 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
