>> If any of these change I must recreate or at least update the CMyBuffer
>> struct.
>You can update the structure in your driver's SetState(). You'll get
>exactly these values from the core and if they have changed. In that
>case the SMF_DESTINATION and/or SMF_SOURCE flags in state->modified are
>set.
>> C. How to know if SurfaceBuffer state changes:
>> <CUT>
>Please check if updating the CMyBuffers in SetState() is enough.
Isn't it true that SMF_DESTINATION and SMF_SOURCE flags are set based on
the blit engine state, rather than the surface buffer state?
i.e. these only provides notification from the core that the operation is
going to occur using different buffers.
I am handling this currently - it is at this point that I grab the new
SurfaceBuffer refs - and create my CMyBuffer wrapper around the
SurfaceBuffer.
However, if my understanding is correct, then this sequence:
1.SurfA->Blit( ... )
2.SurfC->Blit( ... )
3.SurfA->Blit( ... )
presents the SMF_DESTINATION flag for operations 1 and 3 *even if A's
fundamental properties (format,size etc) haven't changed*.
What I'm trying to achieve is some persistant state; so that for each
SurfaceBuffer the user creates I can associate a CMyBuffer.
Then on receiving the SMD_DESTINATION or SMF_SOURCE flags I no longer need
to create a CMyBuffer; it's already available and ready to go.
Jason Barstow.
Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.
Denis Oliver
Kropp
<[EMAIL PROTECTED] To
> Jason BARSTOW
Sent by: <[EMAIL PROTECTED]>
directfb-dev-boun cc
[EMAIL PROTECTED] directfb-dev
<[email protected]>
Subject
11/05/2006 22:52 Re: [directfb-dev] Private surface
state
Jason BARSTOW wrote:
>
>
>
>> Sure. Do you think some callbacks in the graphics driver API like
>> AddBuffer() and RemoveBuffer() or maybe RegisterBuffer() and
>> UnregisterBuffer() would be sufficient?
>> Do you need other notifications like buffer resized etc?
>
> I'll provide some more context:
>
> My backend API funcs look like this:
>
> MyBlit( CMyBuffer* pBuffer, ... )
>
> Currently I must create a CMyBuffer struct that represents the
> SurfaceBuffer - the state it encompasses is video addr, width, height,
> format, stride.
> If any of these change I must recreate or at least update the CMyBuffer
> struct.
You can update the structure in your driver's SetState(). You'll get
exactly these values from the core and if they have changed. In that
case the SMF_DESTINATION and/or SMF_SOURCE flags in state->modified are
set.
> Considerations:
>
> A. How to map CMyBuffer to SurfaceBuffer:
>
> i. Use hash map and manage lifetimes privately.
>
> ii. Private void* member ptr in SurfaceBuffer
I'd also prefer Aii.
> B. How to know when SurfaceBuffer is in existance:
>
> i. Create CMyBuffer for new occurance of SurfaceBuffer (if
> SurfaceBuffer void* pDriverPrv is NULL or not found in hash map table).
> - BUT! How to know when SurfaceBuffer is destroyed.
>
> ii. DFB core provides registration callbacks:
> RegisterBuffer,UnregisterBuffer.
I'd also prefer Bii.
> C. How to know if SurfaceBuffer state changes:
>
> i. Check state on any use - and recreate CMyBuffer on any change.
>
> ii. DFB core to provide callbacks for specific state changes (e.g.
> ResizeBuffer)
>
> iii. DFB core to provide a single callback for any state change
(e.g.
> ReconfigureBuffer).
>
>
> Personally, I like Aii, Bii and Ciii.
Please check if updating the CMyBuffers in SetState() is enough.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
'------------------------------------------'
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
ForwardSourceID:NT0003E0FA
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
