On 8/26/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> Stefan Lucke schrieb:
> > On Samstag 26 August 2006 11:58, Denis Oliver Kropp wrote:
> >> Hi,
> >>
> >> anyone out there with an API change in public or module APIs?
> >>
> >> I just checked in my last API change (graphics driver) and would
> >> like to make the API Freeze now.
> >
> > Did you have a look at the request for retrieving frame-buffer offset
> > required for HW decoding support of cle266 ?
>
> Yes, that was one of my still to be answered mails *sigh*
>
> At least with the introduction of multiple hardware capable
> heaps this method might be insufficient. What about querying
> the physical address? It would still be unclear how the app
> could determine the heap that's used, but it wouldn't be
> ambiguous. In your case you know the physical frame buffer
> base or at least you can find out easily, calculate the offset
> and tell the hardware.
>
> Having n buffers in a surface is also one of my plans for
> the new version. Are you using multiple surfaces instead
> right now?
>
Intresting in my new api concept work I was alson looking at n buffers
for a surface.
The one problem I'm having conceptually is you could allocate buffers
for certain cases
in vram, main memory and shared memory. The problem is the case of a
buffer in main memory here you would not be able to access the buffer
except from the creating process
but in would show up in any list of buffers that is probably global.
The underlying problem is its pretty easy in directfb when you try to
make it very flexible is you too get into situations where a pointer
could be local or remote.
So far the only solution I have if I wanted to allow local/remot is
that the shared data structure has to flag local pointers and these
flags need to be accessed in any data structure that could be shared.
If this is treated is a struct then we should probably have
a generic flag pointer struct.
In the current buffer struct we have the main and video mem struct
split for example.
I'm thinking that simply having a fat pointer struct with flags might be useful.
TypedPointer {
unsigned int32 flags;
void* ptr;
}
The flags could be locks mem type etc. we prob only need 16 bits for
flags the other 16 bits
could easily hold a index into a lock table or other global table. One
cool thing you can do for example with a global lock is lock a fat
pointer even if its local to another process.
Mike
> --
> Best regards,
> Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/ |
> "------------------------------------------"
>
> _______________________________________________
> directfb-dev mailing list
> [email protected]
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
