Hello All,
Can anybody help me on this issue please?
On Thu, Dec 23, 2010 at 3:43 PM, ravi <ravi...@gmail.com> wrote:
> 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
>
--
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
