DirectFB - Home of the pragmatist Roadmap

[directfb-users] Re: Displaying buffer contents
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] Re: Displaying buffer contents


Stefan Nobis <> writes:

> > Is there a particular reason you are using an image provider for this?
> No, but there is no public interface to put data in a surface (and
> even less documentation).

There is a public interface and I showed it to you.
> > It is probably much simpler to create a surface of the right size,
> > lock it, copy your data to the surface (line by line since you need to
> > respect the pitch) and unlock the surface. Alternatively you can also
> Hmmm... first: what is the pitch and how do i respect it?
> Then: How is this supposed to work? I have to use internal headers
> and first i don't like this idea and second is this impossible
> outside the directfb-source-tree (after make install or
> installation form a distributions package system), because at
> least config.h is missing.

You got me wrong obviously. Your solution is the one that needs
internal headers. What I am suggesting works with the exported
DirectFB API.
> > create a surface around your image data. You don't even need to do
> > the copying then. That's what the DSDESC_PREALLOCATED flag is good
> > for.
> OK. Is there any chance to get any useable documentation in the
> near future? I have read the complete online documentation, quite
> some examples and never found any hint how to display a buffer of
> data with directfb.
> To dive into the source for every little bit of work is quite time
> consuming and frustrating.

The API reference manual could indeed be improved but it covers all
the functions I mentioned. All you need for my first suggestion is
IDirectFBSurface::Lock() and IDirectFB::UnLock() while the second one
uses IDirectFB::CreateSurface() only.

> So: I want to display video pictures -- so i get a many frames to
> display. Is there a simple way to say "here is your new buffer" to
> a surface or is it a suitable way to construct a new surface for
> every frame?

Lock the surface, write the data to it, then unlock it.

> There are two buffers for a surface with preallocated buffer. Which
> one it the right to use or is it ok to let both data-pointers point
> to the same buffer?

You need the second buffer only if you want to create a surface with a
pre-allocated backbuffer; this is seldom useful. IIRC this is
explained with the definition of DSDESC_PREALLOCATED in directfb.h.

> What is the pitch field for, what does it mean, which values are
> valid?

Ugh, do I really need to explain this? This is a basic principle of
computer graphics. Perhaps you know it under the name "rowstride".
Basically it's the number of bytes that you need to advance to get
from one row to the next. And, no, this is not necessarily equal to
the number of columns multiplied by the number of bytes per pixel.


Info: To unsubscribe send a mail to with 
"unsubscribe directfb-users" as subject.

Home | Main Index | Thread Index / Development / Old Archives