* Sven Neumann ([EMAIL PROTECTED]) wrote: > Hi, > > Hallvar Helleseth <[EMAIL PROTECTED]> writes: > > > I've been thinking about a new way of using StretchBlit. > > I think StretchBlit could be used to stretch a surface in atleast four > > ways: > > 1. Tileing the source surface to fit the destination surface > > (remove the TileBlit function) > > 2. Scaling up/down the source surface while keeping borders > > (think of Imlib2) > > 3. Tileing the source surface while keeping borders. > > 4. Just scale up/down, like it does today. > > > > A way of doing this could be to add: > > DSBLIT_TILE, DSBLIT_BORDER, DSBLIT_BORDER_TILE to DFBSurfaceBlittingFlags. > > > > In IDirectFBSurface_StretchBlit() (display/idirectfbsurface.c) you could > > check for the blit flags and call the appropriate > > dfb_gfxcard_stretchblit(), dfb_gfxcard_tileblit(), or > > dfb_gfxcard_borderblit() > > > > For a surface to know where the border is I think we need a new API call: > > surface->SetBorder(surface, left, right, top, bottom) > > which would alter the (struct _CoreSurface).left_border/right_border/etc > > Perhaps also the ability to specify the border upon surface creation? > > > > The reason I want all these four functions in StretchBlit is because > > they all stretch blit (part of) a source surface to (part of) a > > desitination surface, just in four different ways... > > > > Or maybe you'd like the four functions to have their own API call ? > > (I really want the border blit function, which I've already > > implemented at the application level, but it's much nicer to have in the > > library since it's such a usefull function!) > > > > Anyways if you give me thumbs up I'll be happy to implement it myself as > > good as I can, and send patches. > > IMO this feature belongs into the application level. It's rarely > useful and can easily be implemented outside of DirectFB if it is > needed. If you think it could be useful for other apps too, why don't > you put it into a utility library so the functionality can be shared > without bloating the DirectFB API? Please keep in mind that we care a > lot about the size of the DirectFB library since our main target is > embedded devices.
Makes sense. This I why I asked _before_ I made a patch. But I don't want to bloat the mailing list with losts of stupid questions either, seeing as you people seem pretty buisy ;) Hallvar Helleseth -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
