On 12/3/06, Pedro Aguilar <[EMAIL PROTECTED]> wrote: > Hi, > > I've used DFB only for developing graphic apps in embedded systems, so > this is what I think (if I understood what Mike said) > > > > > 1.) Refactor the code so all of the current wm is loaded as a shared > > library. Once this is done its up to the WM to provide the DFBWindow > > interface implementation. > > The shared library could be optional when compiling DFB, so if an embedded > system does not use the DFBWindow interface, it can save some space in > Flash. > The library should be small enough (in memory while running, and its > footprint in Flash) for embedded systems (a typical system has 64MB in RAM > and 4MB of Flash). > Exactly most of directfb is quite flexible outside of the window manager / windows this implementation is builtin right now.
Embedded systems have quite a few choices. They can run with no DFBWindow support or they can provide a very simple wm for example a lot of devices only support a small number of windows that can be visible at one time. For example on a mobile you have say 3 windows the top bar center and bottom bar. And two cascading menus and a dialog. The menus and dialog are temporary and can be drawn windows. Other formats are simple tabbed panels for example. Or of course the simplest would be a single top level dfbwindow. And finally of course is a fully custom interface on top of the core layer. Of course over time the merits of custom wm and shared code can be worked out to provide optimized solutions for a range of devices and memory footprints. > > 2.) Consider expanding the concept of a window to be two parts first a > > region for events. > > This is not so important. > > Next consider the current back buffer flip only one operation that can > > be performed to show a window. > > > > I'd like to expand this to be a operator chain of primitives thats > > executed to show a window. > > The design would be similar to opengl. The default operator is to > > flip a back buffer but other operations are possbile. The only > > restriction is that any needed resources such as images would need to > > allocated in shared memory. The base set of operators would be all the > > core > > drawing ops of directfb. > > If I understood well, when an event is received by a window (given that > the window is a region for events), an operator that is associated to this > event is triggered. > This operator could be a chain of primitives. Each chain can be built from > the default primitives that are part of the core drawing ops of DFB, or > from primitives from Cairo or other packages. > > The default and last primitive in the chain, is the flip a back buffer, so > the changes made by the previous primitives are displayed. > In general your correct the last op would be to flip a full screen back buffer in the case of fully drawn windows. The back buffer or buffers are just one primitive operation possible. Although if your really short on ram and have simple drawing unbuffered drawing is possible. Its not a preferred mode but its not precluded. > Should a window be divided into sub-regions, so we can identify different > parts of it, like decorations? > > > For "secure" apps one operator would be a custom callback that exists > > in a shared library loaded into the root process. > > > > Libraries like cairo could be used to generate advanced drawing/blitting > > chains. > > This is a nice idea! The use of Cairo and other GTK+ related packages > could improve the drawing/blitting capacities of a window, but they could > be handled as compile-time options or plug-ins given that they need a > significant amount of resources. > Right. And since Gdk is really a thin wrapper around x11 it makes it easier for me to implement the gtk drawing model. Note this model is not the same as X11 which assume 100% unbuffered drawing but we can provide a compatible model. In the case of gdk directfb I think the following drawing model makes sense. 1.) Either buffer per window or one shared screen buffer works. 2.) A gdk expose is generated for resize and moves. Drawing ops cleared. 3.) Expose is executed drawing ops capture as they are executed. I know what from the time I issue the expose to the end all drawing needed is done. 4.) Ops used to draw the window as needed. I don't need to maintain a buffer. Right now for example if you draw a subwindow and it overlaps you have bleed through because windows are not buffered a expose for a single gdk window results in drawing all child windows since I don't know overlap or other issues. The above approach may or may not be the best solution but at least with the changes I'm proposing I can try a variation of alogrithms for window/subwindow drawing. The coolest thing about this approach over others is you actually have enough information to threshold converting to a blitted buffer based on the time it takes to draw various regions and how often they change so you can do runtime profiling and optimize the drawing depending on a number of parameters. 1.) Given that the time for bliting or flipping various bufferes is fixed ( vram->vram main -> vram etc.) Also the timings for various primitives are known. 2.) Now you can have algorithms that decide to buffer or not based on ram usage and performance this can be done at runtime. This is probably the biggest reason I wan't to take a drawing op approach since it allows the system to do sophisticated optimizatons of drawing at runtime. Finally its not a big leap from here to look at a jit compiler that could generate optimized code. So if you follow the logic the end result is the ability to do some really cool runtime optimization of rendering and thats why I think its the best way to go. It boils down to deciding if it makes sense to execute code to paint pixels or to buffer the output and simply blit or flip. I'm confident that a computer can make the best decision given enough information on this choice and I think that my proposal provides the information needed. > > Comments . > > Please correct me if I didn't get it... > > Pedro Aguilar > > > > > > > > > > > > > > On 12/1/06, Sharma Nitin-A21652 <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I am in. > >> I have collected all the information that I could lay my hands on, in > >> this regard on DFB discussion groups. > >> Please find it attached. > >> > >> Regards, > >> Nitin Sharma > >> > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Aguilar > >> Sent: Friday, December 01, 2006 2:29 PM > >> To: Arvind Ayyangar > >> Cc: [email protected] > >> Subject: Re: [directfb-dev] window mnager for directfb > >> > >> Hi, > >> > >> If you try to port any X based Window Manager you will find a lot of > >> problems because the way X works is completely different to DFB. They > >> were designed with different paradigms in mind. > >> > >> I had a look at different WM, the ones that I think were more suitable > >> for being ported: WindowMaker, Blackbox, Openbox and Matchbox. Since > >> Matchbox was designed for PDAs it seemed the better choice, but at the > >> end all of them have the problem of being designed for X. > >> > >> Mike Emmel had a similar problem with Metacity: > >> http://mail.directfb.org/pipermail/directfb-dev/2006-November/002455.htm > >> l > >> > >> DFB has a windowing system that could be a good starting point for a WM. > >> I'm interested in giving it a try. > >> > >> Regards, > >> > >> Pedro Aguilar > >> > >> > hi, > >> > i am trying to port the matchbox window manager which is designed > >> > specifically for the embedded environment and ran int a lot of > >> > conceptual issues. As I posted earlier, i tried to send these event > >> > through a socket and then tried to use the current dfb api's to manage > >> > >> > windows. But the problem is that both the default window manager and > >> > my WM are handling the events and after a period of time I find either > >> > >> > more than one window in focus or no window in focus at all. > >> > Can someone plz throw some light on this? > >> > > >> > also, si it possible to disable the default WM in DFB? > >> > any recommendation/tip? > >> > > >> > > >> > > >> > > >> > Regards > >> > ARviND AyyangaR > >> > _______________________________________________ > >> > directfb-dev mailing list > >> > [email protected] > >> > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > >> > > >> > >> > >> > >> _______________________________________________ > >> directfb-dev mailing list > >> [email protected] > >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > >> > >> > >> _______________________________________________ > >> directfb-dev mailing list > >> [email protected] > >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > >> > >> > >> > >> > > > > _______________________________________________ > > directfb-dev mailing list > > [email protected] > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > > > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
