nanogui@linuxhacker.org
nanogui@linuxhacker.org
Greg,
Thank you very much for the input. I found the main reason for the slow
speed.
I use ppcboot to load the linux kernel and ppcboot was setting the core to
serialized mode. This makes everything slow as molasses. Everything is
now
much faster. Vncviewer is however still quite slow, not really useable.
Thanks,
Jon Benediktsson
"Greg Haerr"
<greg@censoft To: <nanogui@linuxhacker.org>, <jonb@marel.is>
.com> cc:
Subject: Re: Microwindows on MPC823
12/10/2000
01:08
: 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