Quoting Monge Maurizio ([EMAIL PROTECTED]):
> Alle 18:21, luned� 28 luglio 2003, hai scritto:
> > Quoting Monge Maurizio ([EMAIL PROTECTED]):
> > > Hello.
> > >
> > > Working on Qt/DirectFB code suggested me a couple of things about
> > > DirectFB ( the port is beginning to work pretty well! give a look
> > > at the latest screenshot at qt-directfb.sf.net ).
> >
> > I just checked out qt-directfb from CVS and read through some of the
> > src/kernel/*_dfb.cpp files and I'm really contented ;)
> > It reflects a good knowledge of how DirectFB works and how to use it.
> >
> > My intention was to look for common mistakes like flipping after each
> > drawing operation or not using accelerated methods where possible,
> > but I don't have any serious concerns about your implementation.
> 
> Flippings are satanically optimized thanks to the QPainter class, when
> QPainter::end or QPainter::flush there is a flip of the smallest rect 
> containing what has been drawn. It maybe could be even more optimized
> if it is drawn in two or more little rects whose union is a big rect, 2 
> separate flips could faster, but this will be a paranoic optimization...

I added exactly this optimization to another project a few days ago ;)

Instead of keeping one rect it keeps a list of rects. Each time a rect is
added it iterates through existing rects. The first intersecting rect found
is extended by the new one, otherwise the new rect is added to the list.

This is quite easy to implement and works very good so far.

> > There are some minor suggestions or thoughts though.
> >
> > The DFBCHECK macro shouldn't be used unless you write a small example
> > or testing application. Or did you just keep the name and have your own
> > version of the macro?
> 
> It is mainly for debugging. 
> It can be defined as nothing in a release.
> Maybe there should be a DFBSANITYCHECK macro to check most important
> calls in release too...

I think a general macro for all calls doesn't make sense. Each call should
have it's own error handling, e.g. to deallocate memory or other resources
before returning from a method.

There are also methods that don't really need error handling. These might
use a general macro which is used in debug builds only.

> > You might consider using DFB++ instead. Check out its README and examples
> > to learn about the advantages it has for C++ frameworks. Or is QT required
> > to compile and run without exception handling?
> 
> Not sure, but probably it should...

At least it can be configured without.

> > QSound could be easily implemented using FusionSound which will be the
> > audio sub system for DirectFB desktops.
> 
> Interensting...

I might start with that.

> > Until there's a native window manager with decorations for DirectFB you
> > may use LiTE. Check out the examples, especially window resizing rocks ;)
> > Unfortunately it doesn't work if you are using DFB++.
> >
> > If you don't mind my assistance you could add me as a project member,
> > my sourceforge user is dok666. Working on this with you together would
> > be a great pleasure.
> 
> For me too of course. You have been added immediately.

Thank you!

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


-- 
Info:  To unsubscribe send a mail to [EMAIL PROTECTED] with 
"unsubscribe directfb-dev" as subject.

Reply via email to