nanogui: Thread: Problem: Drawing Images

Hi all,

I am having trouble drawing images, using GrDrawImageBits(),
GrDrawImageFromFile() and GrDrawImageToFit().
I just followed the examples in 'install.txt'.  The examples run fine
on
my x86 PC; however, they only run 'partially' on our ARM platform.
The underlying operating system is uClinux for ARM.

For GrDrawImageBits(), it causes the error:
    # nano-X: GsError (GrDrawImageBits) Bad graphics context:  1000

For both GrDrawImageFromFile() and GrDrawImageToFit(), it endlessly
prints out:
    # nano-X: Error accept failed (88)
where errno of 88 corresponds to:
    #define ENOTSOCK 88 /* Socket operation on non-socket */
It actually finishes drawing the image and then prints out the error
message...
Adding some debug printf's would not reproduce the problem but causes
nano-X
server to stop responding even though the other parts of the system
remain alive.

I tried both 0.89pre8 and 0.89pre7 and the results were similar.

The 'landmine' game and a simple 'hello world' program run fine on our
system;
therefore, I think the nano-X server is ok.

Has anyone experienced the same problems?
Our system is very slow.  Does clock speed have anything to do with
it?  (I personally
do not think so...)

I have trouble sorting out the source of the problems.  Could anyone
give me a hint here?

Thanks. : )


Brian

: I am having trouble drawing images, using GrDrawImageBits(),
: GrDrawImageFromFile() and GrDrawImageToFit().
: I just followed the examples in 'install.txt'.  The examples run fine
: on
: my x86 PC; however, they only run 'partially' on our ARM platform.
: The underlying operating system is uClinux for ARM.

A couple of ideas: make sure that the MAXREQUESTSZ
macro in nanox/nxproto.h is larger than the image
size you're using.  Also, you might try using
the LINK_APP_INTO_SERVER=Y config option so that
you eliminate any client/server issues.  Finally,
there may be some alignment problems in the
image conversion routines - try a few different
types of image files.

Regards,

Greg



: 
: For GrDrawImageBits(), it causes the error:
:     # nano-X: GsError (GrDrawImageBits) Bad graphics context:  1000
: 
: For both GrDrawImageFromFile() and GrDrawImageToFit(), it endlessly
: prints out:
:     # nano-X: Error accept failed (88)
: where errno of 88 corresponds to:
:     #define ENOTSOCK 88 /* Socket operation on non-socket */
: It actually finishes drawing the image and then prints out the error
: message...
: Adding some debug printf's would not reproduce the problem but causes
: nano-X
: server to stop responding even though the other parts of the system
: remain alive.
: 
: I tried both 0.89pre8 and 0.89pre7 and the results were similar.
: 
: The 'landmine' game and a simple 'hello world' program run fine on our
: system;
: therefore, I think the nano-X server is ok.
: 
: Has anyone experienced the same problems?
: Our system is very slow.  Does clock speed have anything to do with
: it?  (I personally
: do not think so...)
: 
: I have trouble sorting out the source of the problems.  Could anyone
: give me a hint here?
: 
: Thanks. : )
: 
: 
: Brian
: 
: 
: 
: 
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
: 

Hello Greg,

Thanks for the message. : )

> : I don't understand
> : why setting MAXREQUESTSZ to a larger value makes such a
> : difference.
>
> There might be a bug in the stack overflow or read
> routine that occurs when the image data is larger
> than MAXREQUESTSZ.  Look at nanox/srvnet.c::GsHandleClient().

For GrDrawImageFromFile() and GrDrawImageToFit(), the request
is so small that it should not cause the stack overflow and besides,
you
have a sanity check on the request size.  It remains a mystery to
me...

> Try turning on or off the ARM structure packing,
> using -mstructure-size-boundary=8 or 1.  The GIF
> routines are in engine/devimage.c.  If the GIF
> code reads in integers or values greater than one
> byte, then the code may not run properly.  If you
> can fix the problem, let me know, I'll update the source
> tree.
I tried both -mstructure-size-boundary=8
and -mstructure-size-boundary=32 flags,
but the problem persists.
I then tried again setting LINK_APP_INTO_SERVER to 'Y' and GIFs
load fine!!!  (I only tried BMP files when I previously set
LINK_APP_INTO_SERVER to 'Y'...)
Does it eliminate the structure packing problem?  It appears to be
more
like a client/server problem.

I'm now scratching my head and wondering why the same code works on
a PC but not on my platform.  I'll try look deeper even though it
seems to
be a daunting task...

Any pointers will be great.

Thanks. : )


Brian

----- Original Message -----
From: "Greg Haerr" ####@####.####
To: "Brian" ####@####.####
Sent: Thursday, January 17, 2002 1:20 AM
Subject: Re: [nanogui] Problem: Drawing Images


> : I don't understand
> : why setting MAXREQUESTSZ to a larger value makes such a
> : difference.
>
> There might be a bug in the stack overflow or read
> routine that occurs when the image data is larger
> than MAXREQUESTSZ.  Look at nanox/srvnet.c::GsHandleClient().
>
>
>
> : However, the programs work for BMPs but not for GIFs.  When
loading
> : a GIF file, the program will not return properly from
LWZReadByte()
> : called from ReadImage() called from LoadGIF().  Does it look
related
> : to the
> : alignment problems you mentioned?  How do I make sure it is the
> : alignment problem and if it is, how do I solve it?  Could you
explain
> : more
> : about the alignment problem?  Structure packing?
>
> Try turning on or off the ARM structure packing,
> using -mstructure-size-boundary=8 or 1.  The GIF
> routines are in engine/devimage.c.  If the GIF
> code reads in integers or values greater than one
> byte, then the code may not run properly.  If you
> can fix the problem, let me know, I'll update the source
> tree.
>
> Regards,
>
> Greg
>
>
>
>
>
> :
> : Thanks again for your help. : )
> :
> :
> : Brian
> :
> : ----- Original Message -----
> : From: "Greg Haerr" ####@####.####
> : To: "Brian" ####@####.#### ####@####.####
> : Sent: Wednesday, January 16, 2002 2:40 PM
> : Subject: Re: [nanogui] Problem: Drawing Images
> :
> :
> : : I am having trouble drawing images, using GrDrawImageBits(),
> : : GrDrawImageFromFile() and GrDrawImageToFit().
> : : I just followed the examples in 'install.txt'.  The examples run
> : fine
> : : on
> : : my x86 PC; however, they only run 'partially' on our ARM
platform.
> : : The underlying operating system is uClinux for ARM.
> :
> : A couple of ideas: make sure that the MAXREQUESTSZ
> : macro in nanox/nxproto.h is larger than the image
> : size you're using.  Also, you might try using
> : the LINK_APP_INTO_SERVER=Y config option so that
> : you eliminate any client/server issues.  Finally,
> : there may be some alignment problems in the
> : image conversion routines - try a few different
> : types of image files.
> :
> : Regards,
> :
> : Greg
> :
> :
> :
> : :
> : : For GrDrawImageBits(), it causes the error:
> : :     # nano-X: GsError (GrDrawImageBits) Bad graphics context:
1000
> : :
> : : For both GrDrawImageFromFile() and GrDrawImageToFit(), it
endlessly
> : : prints out:
> : :     # nano-X: Error accept failed (88)
> : : where errno of 88 corresponds to:
> : :     #define ENOTSOCK 88 /* Socket operation on non-socket */
> : : It actually finishes drawing the image and then prints out the
error
> : : message...
> : : Adding some debug printf's would not reproduce the problem but
> : causes
> : : nano-X
> : : server to stop responding even though the other parts of the
system
> : : remain alive.
> : :
> : : I tried both 0.89pre8 and 0.89pre7 and the results were similar.
> : :
> : : The 'landmine' game and a simple 'hello world' program run fine
on
> : our
> : : system;
> : : therefore, I think the nano-X server is ok.
> : :
> : : Has anyone experienced the same problems?
> : : Our system is very slow.  Does clock speed have anything to do
with
> : : it?  (I personally
> : : do not think so...)
> : :
> : : I have trouble sorting out the source of the problems.  Could
anyone
> : : give me a hint here?
> : :
> : : Thanks. : )
> : :
> : :
> : : Brian
> : :
> : :
> : :
> : :
> :
: --------------------------------------------------------------------
> : -
> : : To unsubscribe, e-mail: ####@####.####
> : : For additional commands, e-mail: ####@####.####
> : :
> :
> :
>
: --------------------------------------------------------------------
-
> : To unsubscribe, e-mail: ####@####.####
> : For additional commands, e-mail: ####@####.####
> :

: I tried both -mstructure-size-boundary=8
: and -mstructure-size-boundary=32 flags,

Try -mstructure-size-boundary=1, that's what the x86
compiler uses. (packed byte arrays)

Regards,

Greg

Hi Greg,

I tried -mstructure-size-boundary=1 but the compiler does not
recognize
it.  The value can only be set to either 8 or 32 for an ARM machine.

Thanks. :-)


Brian

----- Original Message -----
From: "Greg Haerr" ####@####.####
To: "Brian" ####@####.#### ####@####.####
Sent: Thursday, January 17, 2002 11:55 AM
Subject: Re: [nanogui] Problem: Drawing Images


> : I tried both -mstructure-size-boundary=8
> : and -mstructure-size-boundary=32 flags,
>
> Try -mstructure-size-boundary=1, that's what the x86
> compiler uses. (packed byte arrays)
>
> Regards,
>
> Greg
>
>
> --------------------------------------------------------------------
-
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Hello Greg,

I kept trying...
Here's my finding:

in ./engine/devimage.c :
static int
LWZReadByte(FILE *src, int flag, int input_code_size)
{
1336:  for (; i < (1 << MAX_LWZ_BITS); ++i)
1337:     table[0][i] = table[1][0] = 0;
}

I commented out Line 1337 and GIF files are loaded ok now.
Do you know why it is causing the problem?  Stack overflow?
Is there any side affect if the line is commented out?
Displayed GIFs look pretty good.

Any pointers will be great. :- )

Thanks.


Brian

----- Original Message -----
From: "Greg Haerr" ####@####.####
To: "Brian" ####@####.#### ####@####.####
Sent: Thursday, January 17, 2002 11:55 AM
Subject: Re: [nanogui] Problem: Drawing Images


> : I tried both -mstructure-size-boundary=8
> : and -mstructure-size-boundary=32 flags,
>
> Try -mstructure-size-boundary=1, that's what the x86
> compiler uses. (packed byte arrays)
>
> Regards,
>
> Greg
>
>
> --------------------------------------------------------------------
-
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Hello Greg,

I think I have found the problem!!!

For uClinux, there is an extra utility, 'elf2flt', for converting ELFs
to FLATs.
Nano-X server is considered a 'BIG' program for an embedded system,
which exceeds the default stack size set by the elf2flt utility.
After I set
the stack size to a higher value,  the problem is gone without any
change
to the existing Microwindows source tree!

Thanks a lot for keeping me trying.  I really appreciate it. : -)


Brian

----- Original Message -----
From: "Greg Haerr" ####@####.####
To: "Brian" ####@####.#### ####@####.####
Sent: Thursday, January 17, 2002 11:55 AM
Subject: Re: [nanogui] Problem: Drawing Images


> : I tried both -mstructure-size-boundary=8
> : and -mstructure-size-boundary=32 flags,
>
> Try -mstructure-size-boundary=1, that's what the x86
> compiler uses. (packed byte arrays)
>
> Regards,
>
> Greg
>
>
> --------------------------------------------------------------------
-
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####