|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-users] Re: Displaying buffer contents
Hi, Stefan Nobis <email@example.com> 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. Sven -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-users" as subject.