On Mon, Jan 06, 2003 at 03:16:04PM +0100, Peter Graf wrote: > Hi Micah, > > many thanks for your very informative reply. > > >> I'm evaluating which GUI to port to a non-unixstyle multitasking OS with > >> limited posix lib support. Although the CPU performance is more like > >> "embedded", the use is a highresolution desktop rather than a small > >display. > > > >If you're using too big of a display on a small CPU, things will be slow > >without hardware acceleration. If there's any acceleration hardware, > >picogui > >should be able to take advantage of it with the right driver. > > The graphics hardware is simple highcolor, linear memory mapped, > non-accelerated, > but has about 30 MBytes/sec bandwidth. It actually can run Linux+X at > usable speed, > so it should be ideal for PicoGUI+framebuffer with the native small OS.
Hmm.. out of curiosity, what resolution is the display, and what CPU are you using? > > >> Does this mean overlapping PicoGUI windows are only supported via X, > >not on > >> bare framebuffer without X? > > > >For now yes, but this is planned to change. Part of this is the App > >Manager's > >responsibility, and part of it is in the video driver and rendering engine. > > > >Currently PicoGUI's built-in rendering engine doesn't support overlapping > >correctly. However, there is a 'rootless' mode where all top-level windows > >are managed by an external system. This lets picogui do overlapping in X. > >On the framebuffer, you could do the same thing using DirectFB. PicoGUI has > >no DirectFB driver yet, but it wouldn't be much work to write one. > > > >There are plans to rewrite PicoGUI's rendering engine using a pretty nifty > >new algorithm that would make all drawing more efficient, and support > >full overlapping. Once this is done it would be easy to remove DirectFB if > >desired. > > I would like to avoid DirectFB, this hardware wouldn't benefit from > the abstraction of graphics accelerators anyway. IMHO it's mainly a matter of space. DirectFB gives you direct access to the framebuffer so there's no speed penalty, and it's layering model would work nicely with picogui if you want overlapping. If you don't have acceleration you don't have to compile the drivers for acceleration. So, if you're resource constrained and DirectFB would be too big that's one thing, but it would not be a waste of space to use DirectFB. > > Frankly spoken, my problem is the decision between Nano-X (with existing > acceptable window manager, but "old-fashioned" and more client resource > usage) > and PicoGUI (nice architecture, but very young and yet no suitable window > manager.) > > Since FLTK is unusable on my system (lack of C++ compiler for native OS), > and TinyWidgets is no more developed, I tend toward PicoGUI, because it > has promising serverside widgets and themes. > But as things look, I would have to wait for your new rendering engine... > > Can you give me a rough idea how far in the future I can hope for full > overlapping windows support? Are we likely talking weeks, months, or years? Considering I haven't started it yet, and other things come up, at least months until the "S2 engine" is working. If you want overlapping windows and you can run DirectFB however, it would be little work to write a DirectFB driver for picogui and you'd get full overlapping window support. > > Thanks, > Peter > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel -- Only you can prevent creeping featurism! ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
