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.
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.
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. 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.
On 7/23/06, Claudio Ciccani <[EMAIL PROTECTED]> wrote:
> Mike Emmel wrote:
> > On 7/23/06, Claudio Ciccani <[EMAIL PROTECTED]> wrote:
> >> Mike Emmel wrote:
> >> > Attached are the changes to add Get/SetProperty to window.
> >> >
> >> > Plus I added passing in a desc for create subsurface
> >> >
> >> > --- directfb.h 17 Jul 2006 13:12:21 -0000 1.304
> >> > +++ directfb.h 22 Jul 2006 23:33:45 -0000
> >> > @@ -3457,6 +3457,7 @@
> >> > */
> >> > DFBResult (*GetSubSurface) (
> >> > IDirectFBSurface *thiz,
> >> > + const DFBSurfaceDescription *desc,
> >> > const DFBRectangle *rect,
> >> > IDirectFBSurface **ret_interface
> >> > );
> >> >
> >> >
> >> > I'm working now on figuring out how to add double buffering to
> >> subsurfaces
> >> > but this gets the api right for allowing subsurfaces to be equal to
> >> > "real" surfaces.
> >>
> >> ...
> >>
> >> >
> >> > ===================================================================
> >> > RCS file: /cvs/directfb/DirectFB/src/display/idirectfbsurface.c,v
> >> > retrieving revision 1.117
> >> > diff -u -r1.117 idirectfbsurface.c
> >> > --- src/display/idirectfbsurface.c 23 Jun 2006 06:01:37
> >> -0000 1.117
> >> > +++ src/display/idirectfbsurface.c 22 Jul 2006 23:32:50 -0000
> >> > @@ -1920,6 +1920,7 @@
> >> >
> >> > static DFBResult
> >> > IDirectFBSurface_GetSubSurface( IDirectFBSurface *thiz,
> >> > + const DFBSurfaceDescription *desc,
> >> > const DFBRectangle *rect,
> >> > IDirectFBSurface **surface )
> >> > {
> >> > @@ -1936,6 +1937,9 @@
> >> > if (!surface)
> >> > return DFB_INVARG;
> >> >
> >> > + if (desc && desc->flags & DSDESC_CAPS)
> >> > + data->caps = desc->caps;
> >> > +
> >>
> >> You can't change the subsurface's capabilities this way.
> >> Moreover adding double-buffering to a subsurface is the same as creating
> >> a new surface; this may lead the application to run in
> >> out-of-video-memory.
> >>
> >
> > The implementation was not "real" code yet I was just playing there.
> > I have it implemented now and fixed that.
> >
> > And yes thats correct it may run in out-of video memory.
> > Thats up to the application they can try to buffer up in video and if
> > it fails choose to buffer in main memory or not buffer.
> >
> > There is nothing wrong with using up the vram if you want to.
> >
> > Mike
> >
>
> I mean that an application expects that a subsurface will not allocate
> new memory since, by definition, it's only a portion of an existing
> surface. Thus there should be a way to specify if you want a backing
> store or not.
>
> Maybe
>
> IDirectFBSurface::GetSubSurface( DFBRectangle *rect,
> DFBBoolean backing_store )
>
> or (without affecting GetSubSurface())
>
> IDirectFBSurface::SetBackingStore( IDirectFBSurface *storage )
>
> or something similar.
>
> These are only suggestions, maybe you have already implemented a
> similar thing in your "real" code. Please, let me know.
>
> --
> 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
