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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
