> Are you implementing the driver on top of another API that provides its
> own allocation of the data? That's not really supported by the current
> surface core design, but a design which allows implementation even on
> top of OpenGL is being made, well, not actively right now :(
I am allowing directFB to manage video mem allocs itself. I've provided a
primaryAllocateSurface callback and this itself calls dfb_surface_create
with CSP_VIDEOMEMORY.
However there is state I must set up for my private API to use before I can
run an accelerated operation using a Surface Buffer (eg. fill, blit etc).
I'd like to create this state object and have it bound 1:1 with the
SurfaceBuffer. Currently I can create it everytime its needed, buts this is
not efficient.
This does lead me to another question - that I was going to explore today,
but I guess I should just ask:
I believe that the design currently expects video memory to be memory
mapped (via the system backend driver), so that directFB can twiddle bits
directly (and manage video mem surfaces itself). So, I think this means
that the logical surface formats have strictly defined physical formats -
i.e. I can't represent a particular format in an arbitrary way.
Is that right?
>> There can't be anything faster than adding a dedicated and reserved
>> storage in the object itself :)
>>
>> Otherwise, I guess they have a fast hash table for that.
>True, adding a storage member is faster, but it also adds complexity
>to the interface. However, if we're adding accessors to the surface
>state, then more complexity probably isn't too bad, especially if it
>allows quick operation for drivers.
The problem I can see with using a hash map on the CoreSurface or
SurfaceBuffer ptr is that there doesn't appear to be a call back for
surface deletion - correct me if I'm wrong.
So, if the ptr might be reused this would lead to problems. Mmmm, though I
can trap that occurance in my primaryAllocateSurface callback, so perhaps
this isn't so much of a problem.
Thanks for your time.
Jason Barstow.
Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.
"Ben Combee"
<[EMAIL PROTECTED]
.com> To
Sent by: directfb-dev
directfb-dev-boun <[email protected]>
[EMAIL PROTECTED] cc
Subject
21/04/2006 22:50 Re: [directfb-dev] Private surface
state
On 4/21/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> Ben Combee wrote:
> >
> > If your system can use GLib, there's a nice dataset implementation
> > there that lets you store keyed data to go with a private pointer from
> > another library. That might be an efficient and already written way
> > to associate data with IDFBSurface pointers.
>
> There can't be anything faster than adding a dedicated and reserved
> storage in the object itself :)
>
> Otherwise, I guess they have a fast hash table for that.
True, adding a storage member is faster, but it also adds complexity
to the interface. However, if we're adding accessors to the surface
state, then more complexity probably isn't too bad, especially if it
allows quick operation for drivers.
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
ForwardSourceID:NT0003C326
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
