On 7/24/06, Claudio Ciccani <[EMAIL PROTECTED]> wrote: > Mike Emmel wrote: > > My point is its very wrong to have subsurfaces that don't have backing > > stores. > > The problem is we can't handle overlap of subsurfaces correctlly. > > The reality is there badly broken. > > If you mean the "problem" related to Lock()/write/Unlock() on > subsurfaces (not really a problem, only a difficulty, because the API > already provides methods to handle it correctly), it will be "fixed" by > introducing the Write()/Read() mathods suggested by dok. > > > > > Allowing buffering of subsurfaces is one part of fixing there use. > > Next buffered or not when you flip a subsurface you need to allow > > a compisite strategy to deal with sibling surfaces that overlap even > > if your subsurface is not buffered. > > > > I'm adding two things. > > > > 1.) Allow a subsurface to be a first class surface and set its own > > buffering desc. > > We can work on api and how different a subsuface is from its parent. > > Basically a subsurface is simply a surface that has a position on a > > parent and > > can share its parent surface or not. > > > > 2.) Overlap is now allowed for subsurfaces and can be correctly > > handled it was not before. > > This is done by introducing a composite manager. > > Sounds like X. > Composition in DirectFB is already done by the window manager, we don't > need an additional manager. If you want to allow the user to specify > composition rules (shadows and co.), simply write a window manager that > supports user's rules. That's all. >
Overlapping subsurfaces are possible today with our current api. And there handled incorrectly. Maybe I should say WindowManager writer instead of user. > > > > With work we can handle all cases from only a single front buffer not > > double buffering > > your classic drawing mode. Classic unbuffered drawing is not quite > > supported > > since you have to wrap all graphics calls and generate exposes. > > Exposes in DirectFB?! > I was using that as and example if you wanted to write on top of directfb. I don't condone it :) There are use cases for lightweight toplevel windows though such as opaque menus or some types of alerts where it may be better performance to not buffer a window and its always on top. In anycase there are valid use cases. > > I feel > > right now the > > classic case does not need to be supported directly since this is > > really the province > > of a window manager and outside the scope of surfaces execept to record the > > surface overlap information thus the wm would handle clipping and > > exposes if your > > completely unbuffered. > > > > Yet it sounds like X. > Please I was using this is and example implementation on top of directfb. I was not suggesting it in the least. Most X servers are not implemented this way anymore. Note we still have exposes for SubSurfaces that are larger then there parent if there recreated i.e moved or resized. One reason I wan't to add the ability to buffer them. Anyway the final conclusion was the current design is not sufficient for me to write a window manager with all the capabilities I want to have. A set of fairly small changes to surfaces that actually simply takes advantage of existing code and capabilites is all that is needed to support any window manager design. And finally this needs to be split out so the WM can implement IDirectFBWindow interface and its not tightly bound to the core thus allowing freedom of implementation. I can't build what I want to build efficiently on top of the current window implementation. DirectFB internally is cabable of doing what I want its just the design decision with windows prevents it. There is nothing wrong with the current window design it works as intended just it does not meet my needs. In review I realized that with a bit of work on the surfaces and like I said reusing what was already there I could implement the DirectFB window api no problem and also support my needs. And no I don't want to recreate X11 but I use it as and example of something that should be possible if you wanted and you should be able to use the existing api. Not recreate everything on top. > > -- > Regards, > Claudio Ciccani > > [EMAIL PROTECTED] > http://directfb.org > http://sf.net/projects/php-directfb > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
