nanogui: Re: GrGetNextEventTimeout
Subject:
Re: GrGetNextEventTimeout
From:
####@####.####
Date:
10 Oct 2000 01:05:07 -0000
Message-Id: <Pine.LNX.4.10.10010101155170.5050-100000@helios.devel.igelaus.com.au>
On Mon, 9 Oct 2000, Greg Haerr wrote:
> : My boss has requested that I ask if it is possible to get the
> : GrGetNextEventTimeout to be included such that I can use it when I link
> : the server with the app. Currently I get an unresolved symbol.
>
> Yes, I'll work on a version that works with LINK_APP_INTO_SERVER=Y.
> However, for the time being, can you use the non-link-app
> config option? Does Mozilla run client/server? I think it will be
> required that Mozilla run in this way, or we can't run any other
> programs when Mozilla is running. BTW, you will probably want
> to set SHAREDMEM=Y and also increase MAXREQSZ in nanox/nxproto.h
> to your largest image size.
>
Shared memory is set, and I will look into the MAXREQSZ.
>
>
> :
> : With reguard to Mozilla and True Type fonts. I have removed all but one
> : call to GrGetFontInfo (called just after loading the font) and it has
> : increased the page rendering a lot.
>
> Good. What other font info calls or text character size calls
> are you making?
>
The only other time I am using fonts at a Nano-X level is when I am
drawing text with them. All the information I need is stored in the Font
Info structure.
>
>
> :
> : One other small thing. I have had to remove the assertions in the fblin*.c
> : files because Mozilla renders images while they are being loaded. The
> : unloaded portions of the image can (and usually does) contain bad data.
> : I found that removing the assertions did not break any of the demo
> : programs. The way I did this was in each file I changed the
> : #include <assert.h> to
> :
> : #if 0
> : #include <assert.h>
> : #else
> : #define assert(whatever)
> : #endif
>
> You can #define NDEBUG to do the same thing. This will render
> assert() harmless.
>
> However, I'm very concerned that the screen driver is where "bad"
> images clobber the system. I'm aware we have problems when
> decoding a bad image, but there should be no image that blows
> up in the screen driver. Is it the color number that ends up being
> incorrect, from a bad palette entry perhaps? Perhaps just the
> assert(color < psd->ncolors) needs to be removed.
>
Mostly it is the color, but occasionally I have a (w > 0) or (h > 0) But I
have to look into this further to find out why. (Probably a bit of bad
code on my side :)
> Finally, #defining NDEBUG will allow Nano-X to run quicker, which
> is probably fine in a production build, I definitely don't recommend
> it in an engineering build.
>
> Regards,
>
> Greg
>
>
BTW, the code will be available in the next day or too, with instructions
on how to use it. We will also supply binaries that (hopefully) will work
with precompiled nightly builds from mozilla. But we still have to test
the latter.
From Peter Hartshon
