On 7/13/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel wrote: > > I added a call to GetVisibleRect which gives basically the visible > > region of the main surface in the subsurface coordinates seems to work > > but I'm thinking when you lock the surface > > one of the params should be a rectangle that is the visible rect ? > > If someone's using sub surfaces, that one should be aware of the offset > and query the visible region - if needed - itself. > > What about having something like Read() and Write() in IDirectFBSurface > to read/write blocks of data from/to the buffer with automatic locking, > offsets, clipping and *maybe* format conversion?
Hmm yeah something like that maybe in a lot of ways subsurfaces are not a good idea in the sense that a subsurface is not a real surface. Let me get some other stuff checked in then I'm going to add get/set Prop on the core object and send the patch to the list. After that I'm convinced that we need to create a region based abstraction layer on top of core surfaces these regions can share the real surface with there parent or not. Windows should be built on top of that and created by the wm not in the core. Probably this requires a real design to show what I'm talking about. Anyway the point is windows become abstract we have now have collections of regions on top. The window api stays but is really just a wrapper for a region of a surface. Event handling except to designate the region under a mouse event is no longer handled in core at all but in the WM. So the addition would be a region can be buffered or use its parent its up to it. Do you see a problem with that ? Agian its really similar to what you already do in unique but we flip the region stuff into the core and the window/wm stuff out and I'm adding optional buffering or sharing. 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
