Jason BARSTOW wrote: > > > >>> 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.
SMF_DESTINATION is set when switching to a different destination or if the current destination has changed relevant properties like width, height, format, offset, stride etc. > 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*. Ok, so you need to distinguish between a complete switch and changes of the properties. > 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. Each surface has a serial that is increased each time the object is notified, which happens mostly due to property changes. So you might want to do something similar to the serial handling code in state.c. -- 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
