nanogui@linuxhacker.org

nanogui@linuxhacker.org


Subject: Re: Microwindows on MPC823
From: Greg Haerr
Date: Wed, 11 Oct 2000 19:08:38 -0600

: When I run the demos, for example mdemo with the rotating pie chart, the
: rotating pie visibly flickers

The rotating pie chart unfortunately flickers by design.


 and if I close a window, causing the "under
: construction"
: background to be redrawn, that takes about 1-2 seconds to redraw.  Also
: the vncviewer is painfully slow, takes about 10 seconds to redraw a full
: screen.

Yes, this is _way_ too slow.



:
: Our board runs at 50 MHz and has 16MB of SDRAM.  The display is a 640x480
: pixel color TFT, setup for 8 bits per pixel.  The display is set up
: similarly as the
: RPXLITE lcd driver, as a frame buffer device.

Can the display be setup for 16bpp truecolor?  That would help.



:
: I know Microwindows has been used on other MPC823 designs, like Embedded
: Planetīs RPXLITE (LinuxPlanet).  Can anyone comment on the graphics
: drawing speed in Microwindows on the LinuxPlanet ?
:

IIRC, the LinuxPlanet drawing speed is slow.




: I think there must be something wrong, either with my port of Linux to our
: board,
: or there must be some bottleneck in the pixel drawing routines of
: Microwindows.
: I say this because we have run another window system with another OS on
the
: same board and although that window system is very primitive (no clipping
: etc.)
: it was drawing much much faster.

There is a major bottleneck in the image drawing routines in
Microwindows.  Currently, images are drawn pixel-by-pixel,
never using blitting.  Originally this was done just to get images
working, and now it's there because I haven't added the
appropriate 6 different bpp image decode cases to the
image decoders so that the in-core image structure can
be blitted to the screen.  Of course, another solution is to
have cross-bpp blitters.

Having said that, it may be that we should compile in a much smaller
palette that would much decrease the GdFindColor() search time in
the image display routine.  Also #define NDEBUG in drivers/fblin8.c.
There may be other issues, but I suspect these are the big ones.

Regards,

Greg


nanogui@linuxhacker.org