Okay on further thought there is no easy way to run directfb generally with a surface locked. So I think the cairo port needs to be expanded to handle locking unlocking of the surface. Then I think that everything just works tm. Not a problem I know how to do this.
I still think that operations that change the surface pointer and locking unlocking for those and ones that simply need to be locked for hardware accel and don't change the pointer should be treated differently. Basically if the operation invalidates a surface then it should be specially locked. Mike On 7/24/05, Mike Emmel <[EMAIL PROTECTED]> wrote: > On 7/24/05, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > Quoting Mike Emmel: > > > With the addition of Cairo a lot of the drawing is now going through > > > cairo which wants the surface locked while the orginal port assumed > > > the drawing surface was unlocked. I've now reduced the locking > > > problems to one major hack where I unlock the surface after cairo is > > > created to allow cairo to draw direct on a unlocked surface. > > > > How are other cairo backends doing that? > > > > How is the OpenGL backend of Cairo going? > > > > Its not so much a issue of the cairo implementation perse more of > mixing the rendering api's i.e mixing cairo rendering with opegl or > x11 rendering. In opengl they manager the locking and generally the > backends use intermediate surfaces and blitting to handle the issues. > Needless to say they have there own problems if the drawing starts to > use a large number of intermediate buffers. > > For directfb if someone has the surface locked and its unlocked then > there is no trivial way to notify the previous lock owner of the new > surface pointer for example. Just unlocking and locking is not enough. > If your using Cairo and directfb you cannot unlock the surface untill > cairo is finished. Currently the directfb implementation is a mixed > drawing model and that simply does not work. > > There are a number of ways to fix this. > > 1.) Change directfb such that if a surface is locked and we need to > unlock to perform a operation the lock owners are notified and the > surface relocked. Or some similar algorithm. > > 2.) Unify the cairo api and generally work with a locked surface to > not fall into the copying problem that several of the other backends > have. > > 3.) Consider a generic api that does a good job of addressign the > mixing of direct suferface access with the lock primitives. To me the > current directfb api mixes two reasons for locking. > a.) Lock out direct access so the hardware accel can be used. > b.) Flip or move a surface or otherwise change the direct access > pointer such that software rendering needs to reinitialize itself. > > I think the two concepts should be split so software renders only > reallocate there data structures when the pointers are invalid not > because the accleration engine needs to be used. > > I can of course get everything to work without api changes but my > primary goal is to ensure the software rendering has the fastest path > possible and its not clear to me that thats the case now. > > Mike > > > > -- > > 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
