Mike Emmel wrote:
> 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
>
According to me, the regions stuff should remain to the wm.
Moving it to DirectFB itself may result in a loss flexibility because
different window managers may need to implement regions in different
ways. Take a 3D window manager for example.
Instead we could move the StReT stuff out of unique, reimplementing it
as a library or a set of utility functions for window managers.
--
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
