Re: [directfb-dev] Expose event for DirectFb

["Mike Emmel" <mike emmel gmail com>]

If you have child widgets that use subsurfaces and they overlap then
you have a expose type issue.

For top level surfaces you can simulate and expose if you track the
first time the
window was "made visible". This correlates with modern X11 servers that use
buffered windows and only send expose on the first show and on resize
for the window.

Overlapping lightweight widgets forces the toolkit to run its own paint manager
generally using the painter algorithm.

I'm working on a new approach for DirectFB and the surface pools are a HUGE
improvement since they lay the ground works for building composite managers
and window manager as two different concepts.

I'm planning on meeting with Denis face to face in January to go over what
I've done to date and directfb.

At the high level is to remove the current windowmanager from DirectFB and
replace it with  a composite manager thats similar but deals with the
new surface pools.

Then we can build Window Manager suited for different toolkits on top.
For desktop
applications the final result would be similar to the current rootless
DirectFB X11 server and concept.

It probably helps the define the various core pieces.

Graphics Core:
Manages Graphics Card and multi process access.
Provides accelerated drawing surfaces and graphics primitives.
Input drivers.

A composite manager:
Manages a Z ordered tree of surfaces generally
rooted on a screen and assigns certain surfaces as belonging
to different processes.  It also does at least basic routing of events
to different processes generally just the window manager.

Window Manager:
Special client that should be allowed to draw window decorations as
the top level surfaces are composited. Does the actual mapping of input
events to windows. And defines what surface or parts of a surface can be drawn
on by regular applications.  X11 does this with a complex clip.
DirectFB provides a shared surface.
X11 window managers are implemented by catching requests to create a
top level and reparenting.
Since child windows are considered to be widgets is directfb X11 is a
bastard composite, window and partial widget manager.

The current DirectFB Window Manager is really a composite manager that
shares the top level surfaces.
The two concepts need to be split.

So you can see that what needs to happen on the directfb side is we
need to decouple the
compositing of top level surfaces from the "window manager".


In my own work I've introduced the concept of canvas which is just a Z
tree of rectangular regions.

This canvas's can use the parent surface or provide their own.
Painting is down with two methods.
Paint and composite that are callbacks from the Composite manager.
Paint is used to either draw on
the parents surface if you don't have a buffer or into your buffer.
Next composite is called which blits
the buffer to the parent.

This is just a library and now the Window Manager becomes a app that
uses the toolkit to create
widgets called windows.

Applications can use the same canvas toolkit to create widgets.

And finally this system is designed with a declarative canvas in mind
so Window managers can just send
the direct drawing code to the canvas manager so it can draw in the
main composite loop.

Now back to Expose. Its really just a notification that a region is
dirty and needs painting so
its better to call expose a paint event.  So at least for my approach
you will get "paint" events
if needed from the canvas manager that can be sent to the application.

So to finish the new design I want to see is.

DirectFB -> surface pool  and top level composite manager.

Window Manager outside of DirectFB.

In my cases I've split the concept into a canvas toolkit used by both
the wm and apps.

Finally we need to reintroduce DirectFB window's and surfaces and
potentially a canvas manager for the API.
But the provider of the window interface is a pure module with the
current api as a compatibility module.

And finally with all this said what I would like to see is that
toolkits like DirectFB request the style of window manager
they would like to use its up to the developer of directfb  Window
managers to provide the interface if requested.
This way we can explore going to a more complex "beyond windows"
desktop application interface and still
support legacy apps based on X11 questionable drawing model if needed.
Thus you see why I want a rootless X server
like concept so we don't have X11 cruft contaminating the core of
directfb just to support legacy toolkits.










On Dec 20, 2007 9:11 AM, Denis Oliver Kropp <dok directfb org> wrote:
> Sreenivas Chowdary wrote:
> > As far as i know there is no expose equivalent event on DirectFb.
> > There are events for DirectFbWindow like window got focus, keypress,
> > button press, mouse cursor motion etc....
> > We also faced same issue about expose event when porting firefox.
>
> DirectFB does only know about the top level windows and never changes
> their content on its own. So there's no need for expose events sent
> by DirectFB.
>
> A toolkit needs to manage child windows itself and do whatever is needed
> to redraw within the top level window surface. Sending expose events,
> queueing updates or just calling its drawing functions is up to the toolkit.
>
> I don't have a complete overview of all expose, redraw, paint, update, queue
> stuff of GTK+/GDK and the backends. But the code in GDK-DirectFB might still
> need some updates, either for fixing issues or to benefit from improvements
> in the GDK layer.
>
> --
> Best regards,
>   Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/                 |
> "------------------------------------------"
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>