9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] the "disappearing text problem" (experiment results)
@ 2002-05-07  0:25 markp
  0 siblings, 0 replies; 2+ messages in thread
From: markp @ 2002-05-07  0:25 UTC (permalink / raw)
  To: 9fans

well, I'm duly embarrassed. as soon as I sent my mails about the
"disappearing text problem" on the laptops I realized that I forgot to
mention a possibily significant local change... I almost sent a followup
mentioning it, but instead decided I'd wait 'til I had some results to
report just in case it turned out irrelevant.

it wasn't irrelevant. :)

the change: something about the interaction of my less than perfect
vision and the way those yellows display on the LCDs makes it difficult
to discern highlighted text from ordinary text in acme, so long ago I'd
changed the color definitions around /sys/src/cmd/acme/acme.c:846 to
taste. being too lazy to think of any saner color scheme for selected
text at the time, I'd done:

	textcols[HIGH] = display->black;
	textcols[HTEXT] = display->white;


so, I played around and found I could reliably make text seem to
"disappear" by b2ing a command (du -a) that makes an +Errors window with
enough output in it that you have to scroll the window to see all of it.
the output text that's drawn along with the +Errors window was visible,
but output text I saw by scrolling the window with the mouse wasn't.
just solid black blocks.

then I fiddled with the color definitions. it turns out that the text
that wasn't initially visible *is* drawn, but it's drawn in black,
regardless of textcols[HTEXT]. so when textcols[HIGH] is black too, it
looks like it's disappeared.

found that out by trying...

	textcols[HIGH] = allocimage(display, Rect(0,0,1,1(, screen->chan, 1, 0x884488); /* some garish grapey thing */
	textcols[HTEXT] = display->white;

.....and seeing that the du -a output that's visible as soon as the
+Errors window appears is white, but text that appears on scrolling
shows up black.

didn't do the equivalent experiment with rio or samterm, but since it's
the same behavior I expect it's the same deal. also didn't observe any
problems drawing unhighlighted text. (I did the 'cat /lib/words' test)

now all my highlighted text is black on a light light grey background,
which is nicer than white-on-black anyway...


---mp



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [9fans] the "disappearing text problem" (experiment results)
@ 2002-05-07  1:01 markp
  0 siblings, 0 replies; 2+ messages in thread
From: markp @ 2002-05-07  1:01 UTC (permalink / raw)
  To: 9fans

| allocimage(display, Rect(0,0,1,1(, screen->chan, 1, 0x884488); /* some garish grapey thing */

that's a typo. I mean 0x884488ff, of course.



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-05-07  1:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-07  0:25 [9fans] the "disappearing text problem" (experiment results) markp
2002-05-07  1:01 markp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).