9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Re:Q about screenshots
@ 2003-10-07  7:22 a.b
  2003-10-07 13:40 ` mirtchov
  0 siblings, 1 reply; 3+ messages in thread
From: a.b @ 2003-10-07  7:22 UTC (permalink / raw)
  To: 9fans

>And just exactly what happens if the cp occurs while >the screen is in the
>middle of an update.
>Does it grab the old frame, wait for the new frame to >complete, or just
>give you a gibberish dump of the interim buffer >contents which are almost
>certainly worthless?

I don't know it exactly, nevertheless I think the
display is locked when redraw is in process.
So, cp /dev/screen blbla should wait.

Sasa.

________________________________________________________________________________
ZNAČKOVÉ POČÍTAČE DEXX
- vítěz testu herních PC v Computeru 11/2003
- držitel Chip TIP a TIP Počítač pro každého
- cenový trhák -> kompletní PC s 19" monitorem za 19.990 s DPH!
- http://www.email.cz/dexx



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

* Re: [9fans] Re:Q about screenshots
  2003-10-07  7:22 [9fans] Re:Q about screenshots a.b
@ 2003-10-07 13:40 ` mirtchov
  2003-10-07 23:51   ` Charles Forsyth
  0 siblings, 1 reply; 3+ messages in thread
From: mirtchov @ 2003-10-07 13:40 UTC (permalink / raw)
  To: 9fans


> I don't know it exactly, nevertheless I think the
> display is locked when redraw is in process.
> So, cp /dev/screen blbla should wait.

no, you get an image beginning with the first screen and ending with
the updated one -- try it with some of the faster xscr programs, it
almost always occurs..

you can get display locking (man lockdisplay) however most programs
don't use it




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

* Re: [9fans] Re:Q about screenshots
  2003-10-07 13:40 ` mirtchov
@ 2003-10-07 23:51   ` Charles Forsyth
  0 siblings, 0 replies; 3+ messages in thread
From: Charles Forsyth @ 2003-10-07 23:51 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 198 bytes --]

i think that's locking for processes sharing the display
data structures within a shared address space, not locking the
display itself, and indeed that's what {man lockdisplay}
seems to describe!

[-- Attachment #2: Type: message/rfc822, Size: 2265 bytes --]

From: mirtchov@cpsc.ucalgary.ca
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re:Q about screenshots
Date: Tue, 7 Oct 2003 07:40:28 -0600
Message-ID: <38d954a5d27b3145900d481a32aca753@plan9.ucalgary.ca>


> I don't know it exactly, nevertheless I think the
> display is locked when redraw is in process.
> So, cp /dev/screen blbla should wait.

no, you get an image beginning with the first screen and ending with
the updated one -- try it with some of the faster xscr programs, it
almost always occurs..

you can get display locking (man lockdisplay) however most programs
don't use it

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

end of thread, other threads:[~2003-10-07 23:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-07  7:22 [9fans] Re:Q about screenshots a.b
2003-10-07 13:40 ` mirtchov
2003-10-07 23:51   ` Charles Forsyth

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).