| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 968.1 | Sudden exposure... | 17305::WEST | I'm just visiting this planet. | Fri Jun 16 1989 15:55 | 21 |
|
Not real sure what DECterm does with expose events. Normally the client
will receive an expose event(s) when some portion of its window becomes
'visible'. It is the responsibility of the client to process the expose
event since the current implementation of the server does not do backing
store.
I don't think that the DECterm window remembers what has been 'drawn' to
it and therefore has no way to re-generate the image upon receipt of an
expose event.
Sounds like this stat package should do something along this line.
From the sound of your note I don't think that what is happening is a
bug. I could be wrong.
-=> Jim <=-
|
| 968.2 | DECterm does redraw graphics | HANNAH::MESSENGER | Bob Messenger | Fri Jun 16 1989 16:39 | 19 |
| Re: .0
What DECterm does for graphics is to allocate a pixmap the size of the
logical terminal (which is usually but not necessarily the size of the
DECterm window). Any graphics that are written to the window are also
written to the pixmap. When DECterm gets an exposure event (assuming
graphics are visible) it first copies the corresponding rectangle from
the pixmap to the window and then over-writes this with text (which is
kept in a separate display list).
It sounds like what's happening in your case is that DECterm's XCreatePixmap
call is failing, because there isn't enough (off screen?) memory available
for pixmaps. This may relate to a server bug I've heard of where pixmaps
aren't freed properly, or else pixmap space becomes fragmented. Supposedly
this is fixed in VMS V5.2. Maybe one of the server people would like to
comment on this.
-- Bob
|
| 968.3 | Only Regis Terminal Has This Problem | BOSTON::RYAN | Crosseyed and Painless | Mon Jun 19 1989 09:04 | 18 |
| I would like to assume that memory is Okay for this system. It has
16 meg and DECterm does not have any problem restoring other terminal
windows when exposure events occur.
It only happens if the terminal is displaying Regis graphics.
Can anyone else verify this for me? Just display a Regis application
on your decterm window, cover it up with a pull-down window and
then remove the pull down window. In our case, the part covered
is not redrawn.
Maybe it is our machine, but I'm beginning to doubt that.
Thanks to all that have answered so far. The help is appreciated.
Mike
|
| 968.4 | Probably a problem with that particular system | HANNAH::MESSENGER | Bob Messenger | Mon Jun 19 1989 11:49 | 29 |
| Re: .3
> I would like to assume that memory is Okay for this system. It has
> 16 meg and DECterm does not have any problem restoring other terminal
> windows when exposure events occur.
>
> It only happens if the terminal is displaying Regis graphics.
The fact that DECterm can redraw text correctly is irrelevant, since it
redraws text in a completely different way: it stores the ASCII character
codes of the characters in the window and redraws them by calling
XDrawImageString.
> Can anyone else verify this for me? Just display a Regis application
> on your decterm window, cover it up with a pull-down window and
> then remove the pull down window. In our case, the part covered
> is not redrawn.
It works for me in the baselevel I'm running, and it certainly worked in
the SDC version of VMS V5.1. I don't have a VAXstation 3100 (that's
VAXstation and not DECstation, right?) but I haven't heard massive complaints
about a lack of ReGIS backing store on VAXstation 3100s, so it sounds like
some kind of problem with your customer's system. I can't think of what
the problem could be, other than that the XCreatePixmap call is failing for
some reason. Maybe the server process can't expand its address space because
of quotas or SYSGEN limits.
-- Bob
|
| 968.5 | problem in V5.1 ?? | TALLIS::ZANZERKIA | | Mon Jun 19 1989 16:20 | 14 |
| .4
It seems that problem may have been fixed in V5.2
I have SDC VMS V5.1 and it does have problems with sixel graphics
in decterm windows.
type a sixel file in the DECterm window. It paints the file OK
however if you pulldown a menu or overlap a window the background
leaves a hole in the display.
This is on VaxStation II, 13MB, mono.
Robert
|
| 968.6 | I haven't seen V5.1 run on all configurations... | HANNAH::MESSENGER | Bob Messenger | Mon Jun 19 1989 20:51 | 12 |
| Re: .5
Nothing was changed in DECterm in V5.2 that could have affected the way it
redraws graphics (although as I've said I've herd that there was a server
change that could affect this), and both ReGIS and sixels should be redrawn
from the backing store (although sixels aren't always redrawn in the correct
colors on monochrome systems). I haven't tested V5.1 on a VAXstation II mono,
though; so maybe there's some kind of problem on both VSII and VAXstation 3100
systems.
-- Bob
|
| 968.7 | Coupled to DECterm scrolling | CZARS::MCGUIRE | Software Driven | Tue Jul 11 1989 13:58 | 12 |
| I realize this may be a bit late, but it takes me a while to catch
up with this conference :^)
Running SDC Decwindows 1.0/VMS 5.1 on a 32 MB VAXstation 3500 I have
observed the following behaviour. If vertical scrolling (in DECterm)
is enabled then obscured REGIS images will NOT be refreshed. If
vertical scrolling is disabled then obscured images will be properly
redrawn.
-Gerry
|
| 968.8 | Check the Source -> Release Notes! | SKRAM::SCHELL | Mark Schell, SWS, Carolinas District, 367-7040 | Tue Jul 11 1989 23:40 | 12 |
| > Running SDC Decwindows 1.0/VMS 5.1 on a 32 MB VAXstation 3500 I have
> observed the following behaviour. If vertical scrolling (in DECterm)
> is enabled then obscured REGIS images will NOT be refreshed. If
> vertical scrolling is disabled then obscured images will be properly
> redrawn.
Thot I remembered something about this in the VMS 5.1 release notes. I
think this is currently a restriction or limitation.
Mark
|