Re: Display Memory
- From: Liam Quin <liam holoweb net>
- To: Bluez Zhao <zhyforever 263 net>
- Cc: gtk-app-devel-list <gtk-app-devel-list gnome org>
- Subject: Re: Display Memory
- Date: Thu, 4 Jan 2001 21:44:23 -0500
On Fri, Jan 05, 2001 at 08:46:09AM +0800, Bluez Zhao wrote:
Yes, I want to implement a screenshot and want it as
fast as quick. But as you know, if the desktop is using multiple visual
types, it will take a long time to query the window tree and determine the
area of the same visual type and get it's image. Someone told me that in the
display memory each pixel is stored as 32 bits. So I wander if I can get
that memory directly. Can you give me any suggestion?
That depends n the hardware. In a multiple plane group framebuffer, as found
on SPARC systems and (less often) on PCs, the 8-bit windows are generally
stored in separaet memory than the 32-bit or 24-bit or 16-bit windows.
As a result, yes, you need to do the queries.
Sun's "snapshot" does a good job, but I don't remember if the source
for that is around, with a BSD-style license if it's part of XView.
Also xv, but that's shareware.
The other problem you will have with accessing the frame buffer directly
is that when an 8-bit window obscures a 24-bit one, the underlying 24-bit
plane is likely to have garbage "underneath", but might not; only the
X server knows for sure.
As always with performance issues, first try it the simple way and
measure it, and see if it's fast enough. The biggest overhead will be
transferring the image data to the client, however you get at it, and
if you use X your code can work on remote displays too.
Lee
--
Liam Quin - Barefoot in Toronto - liam holoweb net - http://www.holoweb.net/
Ankh: irc.sorcery.net www.valinor.sorcery.net irc.gnome.org www.advogato.org
author, The Open Source XML Database Toolkit, Wiley, August 2000
Co-author, The XML Specification Guide, Wiley, 1999
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]