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.
>
> 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 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.
--
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
