[lisaem] Re: Mouse keeps getting stuck

From: Ray Arachelian <ray_at_email.domain.hidden>
Date: Thu, 15 Mar 2007 17:07:58 -0500

Jerome Vernet (Orange) wrote:
> I finally build a working PPC build for 10.4.7. Seems to be much slower
> than the 10.3 build. And the speed reported goes from 0.1 Mhz to 270 Mhz ;).
>
Unless I got the mhzactual math wrong (and that's quite possible), it probably is the equivalent of
that speed, and it seems slower because it no longer responds to UI events while it's stuck in a
very tight loop.

                mhzactual= 0.001 *
                          ( 
(float)(cpu68k_clocks-last_runtime_cpu68k_clx))  /
                          ( (float)(elapsed-last_runtime_sample) );

So the 0.001 is to turn 1/5MHz elapsed cycles into milliseconds. The elapsed - last_runtime_sample
are in milliseconds. The cpu68k_clocks/last_runtime_cpu68k_clx are in cycles.

So the way the MHz actual code should work is that it gets the cpu68k_clocks difference which is the number of 5MHz cycles, and compares that to the number of milliseconds that have passed, then based on
how much time has passed to execute that many cycles says this is the equivalent of running at X Mhz.

Do I have the right formula there?

> I add some optimization flag to build.sh, but with -fast -mcpu=7450
> (turn on all optimization option on), Lisaem doesn't build (error on
> link, I think due to gcc bug).
>
Yes, be very careful with the generator core code. It seems to run out of registers to spill if you
do that on intel. Not sure where it'll break on PPC. That's why that code is marked with -O2
(I think.)

> So I only add -03 -mcpu=7450
>
> I also try -ftree-vectorize, some more speed up (may be ;))
>
> Some strange thing:
>
> *Power off doesn't work very well (some strange windows bugs happens:
> windows goes nearly full screen, Lisaem seem to hang but still respond
> slowly to menu command).
>
That is very very strange. Any chance you could turn on profiling and let me know what you find?
I'm still a bit new to OS X. :-)

There are two things that happen at power off. One is that the printers are flushed. You really
should only have a single printer, if you have more, this step will take a lot of time. Even a single
printer will be a bit expensive at power off. (It's trying to see if there's any data in the page frame
buffer, if there is, it will print it, or produce an image, after that it deletes the printer object.)

The other is the contrast change. LOS will dim the screen slowly. It turns out that the
ContrastChange method is much slower on OS X than on other platforms.

This is why this has a define around it in the beta 2007.03.15 beta 2 code at the bottom of void LisaWin::ContrastChange()

#ifndef __WXOSX__ // 2007.03.14 disabled for os x since it slows down shutdown a whole lot

    force_refresh(); // win32 still has contrast-trails. :-( 20070216
#endif

On windows, if you launch lisaem and go and do other things, then come back to LisaEm, you get Contrast-trails until the next full refresh. I've not seen this on Linux and with OS X's double buffering, it never happens there.

By the way, the Right mouse button forces a screen refresh if you ever need it. Received on 2007-03-15 17:08:04

This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:14 EST