From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 13 Jan 1996 02:36:55 -0500
From: G. David Butler gdb@dbSystems.com
Subject: 8 1/2 windows can't be created
Topicbox-Message-UUID: 3a21dd5a-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19960113073655.NQO2dSM6SO_SyVJxo7anmiPmIl4pZYw216llIYmB1Aw@z>

I, "G. David Butler" <gdb@dbSystems.com> mumbled:

>Has anybody else noticed that when using a 1280x1024x8 (i.e. large)
>vga screen, that you can't create two (or more) large overlapping
>windows?  The new one you try to create disappears after sweeping
>with either New or Resize.

Or even moving a large window.

>To try to find the culprit I did a direct mount to /srv/8.. and the
>mount fails with "no resources".  After increasing kernelpercent to
>50 I got it to open bigger windows, but increasing kernelpercent after
>that doesn't seem to help (I have 8meg in my PC terminal.)

>After looking in the source it seems that the problem may be with a
>fixed size array.  In /sys/src/libg/binit.c there is an array
>static uchar bbuf[8000] (and _btmp[8000]).  In other places it seems
>a malloc would have to fail, and I think there is enough memory.

Wrong.  This array is used to format messages to the bitblt driver.

>Before I start changing and rebuilding I thought I would ask if anyone
>has run into this and if this was the solution.

OK, I have this one tracked down.

If you are using a large screen, the bitmap code allocates arenas of
as large as 1,310,732 bytes and with only 8 meg of memory things are a
bit tight with a few of these.

The best balance for my configuration was to set kernelpercent=65 and
that allows for 3 arenas which allow me to create all the windows I need.
(Of course with only 196 pages of memory left for processes, a cpu
server is *very* handy.)

To determine the best mix for your machine (this is PC specific), use
the ^t^tb and ^t^tx keyboard strokes to get a dump of the bitmap
and kernel memory pools respectively.  What I did was get the bitmap
to allocate 3 arenas with about 150K in both the xalloc and malloc areas
remaining.  This is what gave me the kernelpercent at 65.

David Butler
gdb@dbSystems.com