Well, if your requirement is at base to return a pointer to the pixel data in
the framebuffer, then Lock is the way to do it. You should then leave the
surface locked until you use that pointer and are done with it, when you can
safely unlock it. You could do that for example with standard reference
counting, or a simple flag.
My point was, that the requirement you have been given (return a pointer etc)
may be more restrictive than it need be. Perhaps the real requirement, for
example, is that some function be able to read the pixel values from some
region, or to write those values so they can appear on the surface - in which
case there are other ways to do it. And the requirement you have, lets you
return only the pointer and pitch, but the user will then also need to know
things like the PixelFormat - and to assume things such as that the pixel map
is
indeed a contiguous memory map, and the pixel format indeed matches that
returned (rather than both of these being abstractions, which is formally what
they are). For example some systems abstract the frame buffer so that to
DirectFB it appears as a contiguous memory map with the DirectFB pixel formats,
but in fact it is fragmented: when you use the API it is fine but if you access
via pointer it is not.
==================================
Chris Bore
Training Director
BORES Signal Processing
ch...@bores.com
www.bores.com
+44 (0)1483 740138
________________________________
From: ravi <ravi...@gmail.com>
To: Chris Bore <chris_b...@yahoo.co.uk>
Cc: Sriram Neelakandan <sriram.neelakan...@gmail.com>;
directfb-users@directfb.org
Sent: Thu, 23 December, 2010 9:22:12
Subject: Re: [directfb-users] accessing the row
i have a function to implement that returns a pointer to an array of pixels
representing the
pixels in the specified row , or else returns NULL if an error occurred. If
successful, the returned
array pointer may point to a temporary buffer or directly into the frame buffer.
(The latter is usually desirable, if possible.)
On Thu, Dec 23, 2010 at 2:42 PM, Chris Bore <chris_b...@yahoo.co.uk> wrote:
Although it is used in DirectFB, I do not recommend using the Lock/Unlock
functions. They bypass the API, and raise other issues that can be
problematic.
I do not think there is ever a case where using Lock to gain direct access to
the encapsulated pixel data is really necessary - it can always be done using
the standard API. If you explain what you are trying to do then perhaps I can
suggest another way to do it.
> ==================================
>Chris Bore
>Training Director
>BORES Signal Processing
>ch...@bores.com
>www.bores.com
>+44 (0)1483 740138
>
>
>
>
>
________________________________
From: ravi <ravi...@gmail.com>
>To: Sriram Neelakandan <sriram.neelakan...@gmail.com>
>Cc: directfb-users@directfb.org
>Sent: Thu, 23 December, 2010 4:58:32
>Subject: Re: [directfb-users] accessing the row
>
>
>
>If i unlock the surface first then how can i return the pointer to the caller?
>I'm unlocking the surface in a different function that caller will call after
>this function.
>
>On Thu, Dec 23, 2010 at 10:02 AM, Sriram Neelakandan
><sriram.neelakan...@gmail.com> wrote:
>
>well that means the surface is already locked .. u must unlock each Lock after
>usage
>>
>>1. Lock
>>2. use the pointer
>>3. UnLock
>>
>>
>>
>>On Wed, Dec 22, 2010 at 4:31 PM, ravi <ravi...@gmail.com> wrote:
>>
>>Hell,
>>> i have a function to implement that returns a pointer to an array
>>> of
>>>pixels representing the
>>>pixels in the specified row of the surface columns from x (inclusive) to x +
w
>>>(exclusive), I implemented it like this......
>>>
>>>
>>>{ void *data;
>>> int pitch;
>>> surface->Lock(surface, DSLF_READ, &data, &pitch );
>>>
>>>
>>>return (pointer *)data + pitch*row;
>>>
>>>
>>>}
>>>
>>>
>>>running this function is aborting the program with this message......
>>>
>>>
>>> DirectFBError [>surface->Lock( surface, (DFBSurfaceLockFlags)(DSLF_READ |
>>>DSLF_WRITE), &data, &pitch )]: Resource is locked!
>>>
>>>
>>>
>>>
>>>--
>>>Regards
>>>
>>>Ravi Swami
>>>EnMedia Software Technologies
>>>Ph +91-974-264-3747
>>>
>>>_______________________________________________
>>>directfb-users mailing list
>>>directfb-users@directfb.org
>>>http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
>>>
>>>
>>
>>
>>--
>>Sriram Neelakandan
>>Author - Embedded Linux System Design And Development
>>(http://tinyurl.com/2doosu)
>>
>
>
>--
>Regards
>
>Ravi Swami
>EnMedia Software Technologies
>Ph +91-974-264-3747
>
--
Regards
Ravi Swami
EnMedia Software Technologies
Ph +91-974-264-3747
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
