>If it's not the first allocation for the buffer then clearing >it would just waste resources since the surface core will >overwrite it with the old data anyway.
Just for buffers with a video low and video high policy though, right? I don't think there would be any old data to back video only with. >I just cooked up the >attached patch that should clear only the first allocation for >each buffer. I just implemented it in the surface core with >CPU access to make it simple and generic. Thanks, I'll check it out. This would be expensive though if the GPU could do the clear and I'm not sure it is always desirable. For example, I know of some certification tests were >2000 surfaces are created and destroyed per frame. Considering clearing scenarios - for single buffered display layers a clear is definitely needed, but for double/triple a DSCAP saying to clear or not might be nice for a client to be able to use. The DSCAP could then also be used for non-visible/off-screen surfaces. In one use case, the client might want the surface automatically cleared (for example they intend to only draw to a part of it). In another, the client would not want it cleared because it would be fully initialized by an image provider. It seems strange to me that there is not already an intention/policy with regard to non-visible surface clearing approach and for display layer surfaces. If there really is an unwritten one, it would be helpful to know for us developing our own systems drivers and surface pools. BTW: Regarding clearing display layer surfaces, I am not having success with the directfbrc init-layer=0,bg-color=FF000000 style commands performing as expected prior to flip compared to doing a clear in my surface pool AllocateBuffer function. However, perhaps that is because a wait idle needs to be done prior to flipping each initialized layer... Regards, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel >-----Original Message----- >From: Ville Syrjälä [mailto:syrj...@sci.fi] >Sent: Wednesday, May 20, 2009 12:45 PM >To: Strelchun, Timothy >Cc: 'directfb-dev@directfb.org' >Subject: Re: [directfb-dev] To clear or not to clear in >CoreSurfaceBuffer allocation handler in a surface buffer pool > >On Tue, May 19, 2009 at 05:32:06PM -0700, Strelchun, Timothy wrote: >> I just realized a behavior change in our new DFB 1.2 based >systems driver as compared to our previous 1.0 based driver... >> >> Newly created visible and non-visible surfaces do not appear >to be cleared after they are allocated (previously done by >default window stack I believe). >> >> Is it an expectation of a CoreSurfaceBuffer Pool Manager to >clear newly allocated raw pixel buffers? > >If it's not the first allocation for the buffer then clearing >it would just waste resources since the surface core will >overwrite it with the old data anyway. I just cooked up the >attached patch that should clear only the first allocation for >each buffer. I just implemented it in the surface core with >CPU access to make it simple and generic. > >-- >Ville Syrjälä >syrj...@sci.fi >http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
