Tanjore Suresh wrote:
Hi,
I am using DirectFB 1.3 version. When does one implement surface pool bridge interfaces?

When a more efficient way of synchronizing two allocations of the same
buffer can be provided. It should be faster than the fallback which tries
to lock both for CPU access (one read, the other write) and does memcpy, or
uses Read()/Write() of one of them combined with a lock on the other.

There's no fallback, yet, that uses both Read() and Write() which would
require a temporary third allocation.

I am the process of developing the prototype systems and drivers for our graphics requirement. While debugging that code to set the background to be an image(.dfbg), it creates an image provider and then allocates a surface and renders into that surface created by itself. Subsequently, it tries to copy/bridge to the surface that our system's can manage.

Does your surface pool provide locking (virtual address mapping) for the
CPU to access the allocations?

If so, you might try raising the priority to have the buffer allocated
in your pool right away. The unpublished surface core extensions are
better in that regard. Still planning to release pre-2.0 code...

Currently, i have not supplied the surface pool bridge interfaces. The routine which calls surface pool bridge interface does not seem to check for the return code. Becuase of that setting background with an image does not function well under my environment.

The bridge must not fail, if it returns success in CheckTransfer(),
that's true, I think.

Can some one please let me know when do you supply the surface pool bridge interfaces and also please reason out why it need to be supplied?. Is there any means to overcome it without bridging as it saves a copy of pixel data.

The bridge doesn't save a copy on its own, but to avoid multiple
allocations of the same buffer (check via dfbdump -a -p) your pool
should provide read/write locking for the CPU in addition to the
(probably handle based) support for your GPU. Then it might just
need a higher priority :-/

--
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

Reply via email to