Thanks Chris. I've done that exercise. i implemented the function like this:
{
surface->Lock(surface, DSLF_READ, &data, &pitch );
return (pointer *)data + pitch*row;
}
I'm unlocking the surface in a different function that caller will call
after this function.
running this function is aborting the program with this message......
DirectFBError [>surface->Lock( surface, (DFBSurfaceLockFlags)(DSLF_READ |
DSLF_WRITE), &data, &pitch )]: Resource is locked!
Can you please help me to understand this phenomena?
On Thu, Dec 23, 2010 at 3:32 PM, Chris Bore <chris_b...@yahoo.co.uk> wrote:
> 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
>
--
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
