Good questions I'll send this to the list I think its important. My current work will be easily accessible soon. It has a sponsor and they have not set up a public access repository yet. Nothing mysterious just administrative.
Evas like a lot of opensource frameworks did too much on one hand and not enough on the other. We have a great declarative language svg and others such as pdf. So whats needed for directfb in my opinion is a clean conversion of these to declarative form. I simply see no reason to not use a DOM. Given this you realize that their exist a infinite number of potential declarative languages. And they have a complex relationship between the tags or commands or state machines that change the drawing. A webbrowser is a perfect example. So instead of trying to create the declarative programing language I created a frame work that was declarative friendly. And one key point is these are layout/drawing languages not just drawing a graphics primitive drawing canvas does not solve the real problem and layout depends on a complex inter tag relationship. The layout problem is far harder than the declarative drawing problem and more important. You have to handle both. Evas is not really a layout engine and splitting layout and drawing does not make sense to me. Now even though you can't create the one true declarative language drawing is drawing and they all should eventually share a common set of primitives but this implies a compiler like design which is not really Evas. Denis is working on a low level declarative canvas for directfb we need to sync but this is the research part of the project which is to determine the primitives that should be exposed and also to show that you can reduce a arbitrary complex layout/drawing language to a clean set of primitives. PDF shows that its highly probable you will succeed for the most part. Whats more interesting is when you fail to convert how do you handle that. Next of course you want to target the GPU not the CPU. Some work already exists on simple JIT compilers for GPU's but this is really a R&D project and I'm taking the top down approach. Denis is thinking bottom up. But whatever we come up with the drawing code will work withing the context of a layout engine. I have successfully implemented the concept of providing a canvas infrastructure for a complex declarative language so the end user does not have to worry about the internals. Right now my canvas's simply call paint and composite on the drawing engine. But this is a implementation issue the key user is now free to write any declarative language and its associated processing engine. Evas could be one of the supported engines but its far less flexible than existing browser engines I'd rather expose the browser over time is a drawing engine toolkit for new layout/drawing languages. On Dec 21, 2007 2:56 AM, Pedro Aguilar <[EMAIL PROTECTED]> wrote: > Hi Mike, > > I haven't had time for coding these ideas (that we discussed some months > ago ), but I still think it's the right way to go. > Some time ago I managed to remove the DirectFB surface code and put Evas > inside it since it does what we want. I remember you made the same > experiment but now I see you are developing your own, although I didn't > found it in the git repository, from where can I download it? > > Why did you choose to develop your own instead of using Evas? We said that > inserting Evas into DirectFB was not that straight forward, but could have > several advantages like proved stability and performance. > > I understood the rest of the things you describe since we already talked > about them, my problem is just the lack of time... > > I hope to have time during the following months, is there anybody else > that have shown some interest in the project apart from Denis? Is there > any available code that implements (even partially) these ideas? > > Thanks! > > Regards, > -- > Pedro Aguilar > > > > > 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 > > > > > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
