Re: W1r2 - great!

[Tamminen Eero <t150315@proffa.cc.tut.fi>]

> > > Windows should be a bit faster after TeSche incorporates my dither
> > > stuff to W1R2 (it's for W1R1, and I was to lazy to do the conversion

Err... I did it after all. It will need some changes to W though as
function arguments have been changed.

> > Good!  Right now I can see it drawing each line of the fill in the
> > window title bar even when my system isn't too loaded.
>  That still holds for much faster systems like a Sparc2. :)

Yesterday I noticed that you have forgotten to replace the loop for
plotting the pixels one by one with a higher level function (eg. dbox).
No wonder it takes some time :-).


> > > As all blocks go through a socket that's a bit slow. If running on

> > Ah, but that's not a W program then, is it?  :-)  I'm going to try to

For picture viewing Mgif (has / works with both the GEM and text interface)
is best. It restores the screen, works on all resolutions (even without
GEM), is fast, understands IMGs, GIFs, Jpegs etc...

> > modify the server and Wlib to use shared memory for speeding up images.
>
> > Of course, this means delving into the guts and wrecking everything.

We have discussed about that...  It would probably be best to have a
separate function (I assume that it would use those easy MiNT functions,
not SYSV stuff) that sends the SHM file name to server, which would
reply with an identifier recogniced by server.  Later putblocks would
then just transfer the id and co-ordinates.  The trouble would come if
our program would die without sending a message that would instruct the
server to close the SHM (without which the shared memory wouldn't be
freed), so you'll probably have to have some kind of list about SHM's
open on the server side.  Currently window, rect etc.  structs on the
server side are on a statically allocated area to avoid memory
fragmentation.

Shared memory would of course work only locally although the server
and apps can be run on different machines (have you tested this TeSche?).


>  Suggestion has been to write SysV compatible wrapper routines around the
> MiNT-SHM. I think this is the best idea. They might even go into the MiNTLib
> later. Anyone want to do it? I've currently no MiNT running.

For portability that would be best. MiNT SHM seems much easier to use
though :-).


	- Eero