Re: [ZooLib-dev] Compilation error on BeOS

[Andrew G. <ag...@em...>]

> /boot/.../ZString.cpp: In function `static class string  
> ZString::sFromStrResource(short int)':
> /boot/.../ZString.cpp:259: aggregate `struct app_info info' has
> incomplete type and cannot be initialized
> /boot/.../ZString.cpp:260: confused by earlier errors, bailing out
> make: *** [ZString.o] Error 1
>
> Any ideas?!

AndreasKaenner posted a message to the zoolib forum on SourceForge with the
following mods for BeOS compilation:

I had some problems to compile the helloworld example. Here are my fixes:

ZDCRgn.cpp --> line 685:
virtual ~FakeBRegion() = 0;

ZUIUtil.cpp --> insert before line 46:
#include <app/Roster.h>

ZString.cpp --> insert before line 246:
#include <app/Roster.h>

Although we checked the demo apps under the various OSes, It's clearly the
case that we never built under BeOS 5.0.

When I'm working on the core library features it's a massive timesaver for
me to have just a single copy of the source that's accessible from all my
build machines -- I can make a change to implement or fix a feature for one
OS, and trigger a build on all the others to be sure that I didn't break
something elsewhere. I keep a single copy of the zoolib source on a linux
server running netatalk, samba and NFS. netatalk provides access from my
MacOS machine, samba does the same for Windows and NFS lets me access the
source from BeOS 4.5. Unfortunately, and I have reported this to Be on
several occasions, under BeOS 5.0 neither Andreas Huber's NFS filesystem
driver nor the SMB support that ships as part of BeOS 5.0 work for gcc's
purposes. So for BeOS I still run 4.5, and thus didn't catch these 4.5/5.0
problems. Sorry.


> And then another question. I plan to use zoolib for a graphics
> intensive app mainly for BeOS and Windoze. Does anyone have experiance
> with
> zoolibs graphic speed (lines, polygones, circles...).

It all depends on what you're doing. For example, ZooLib lets you have
multiple ZDC's that all reference the same destination, but maintain
different origins, inks, clip regions etc. If you plot a pixel through one
ZDC, then plot a pixel through another, then go back to the first, the vast
majority of the CPU's effort will be expended in pushing state values from
the ZDCs into the native port. But if you set up a ZDC, then make several
calls to fill shapes, the port will be configured only when the first call
is made, and the overhead of subsequent calls comprises a virtual method
dispatch, the comparison of a few change counts, and some math to convert
coordinates; the vast majority of the time will be spent by the native code
writing pixels to the port and the overhead will be unnoticeable.

What's likely to be most important in real code is actually how one goes
about building up an image. For example, I had a 16 by 16 palette of color
chips in a menu implemented with ZooLib. Under BeOS on my laptop I could
*see* the chips ripple into the menu, but a similar menu implemented by
another BeOS app just appeared instantaneously. Obviously this bothered me,
so I wrote a purely native version. It *also* rippled onto the screen. I
went back and forward on this with Benoit at Be -- my native code was taking
450ms, the ZooLib code was taking roughly the same. When I simplified the
code to *not* draw a one pixel frame around each of the 256 color chips my
time dropped to 60ms. But on his machine it was taking 2ms. Clearly the
problem was my laptop's graphics driver -- the frames were being drawn by
BeOS making four additional calls to the graphics driver's fill rect
operation, and that operation was just slow (go figure). The similar looking
palette from another BeOS app appeared instantaneously because it was being
blitted from offscreen. The performance problem was not in ZooLib, but in
how I'd decided to image the palette.

The upshot is that on average there's a fairly fixed overhead per call. That
overhead is not large in itself, but for very simple operations it might
make a difference in some circumstances. But it's likely that in those
circumstances the overhead of the native call itself is also significant,
and thus it would be better to have hand coded some alternate implementation
in any case.

A
__________________________________________________________________
Andrew Green                                  mailto:ag...@zo...
The ZooLib Guy                               http://www.zoolib.org
350 25th Avenue, Suite #1                   Vox: +1 (415) 831 2471
San Francisco, CA 94121-1912                Fax: +1 (415) 831 2472