nanogui: Big GrArea under client/server Nano-X
Subject:
Big GrArea under client/server Nano-X
From:
Morten Rolland ####@####.####
Date:
17 Dec 1999 17:13:21 -0000
Message-Id: <385A7B9B.90A25898@screenmedia.no>
Hello!
During testing, we found that large images don't work well with
the GrArea call in 0.87pre1 due to a 64K limit on the protocol
request size. The following patch seems to fix the problem from
the client side:
--- mwin-0.87pre1-orig/src/nanox/client.c Thu Dec 2 07:52:03 1999
+++ mwin-0.87pre1-bigarea/src/nanox/client.c Mon Dec 13 16:51:09 1999
@@ -915,21 +915,31 @@
GrArea(GR_DRAW_ID id, GR_GC_ID gc, GR_COORD x, GR_COORD y, GR_SIZE width,
GR_SIZE height, PIXELVAL *pixels)
{
nxAreaReq *req;
long size;
+ int chunk_y;
/* FIXME: optimize for smaller pixelvals*/
- size = (long)width * height * sizeof(PIXELVAL);
- req = AllocReqExtra(Area, size);
- req->drawid = id;
- req->gcid = gc;
- req->x = x;
- req->y = y;
- req->width = width;
- req->height = height;
- memmove(GetReqData(req), pixels, size);
+
+ while ( height > 0 ) {
+ chunk_y = 64000 / ( width * sizeof(PIXELVAL) );
+ if ( chunk_y > height )
+ chunk_y = height;
+ size = (long)width * chunk_y * sizeof(PIXELVAL);
+ req = AllocReqExtra(Area, size);
+ req->drawid = id;
+ req->gcid = gc;
+ req->x = x;
+ req->y = y;
+ req->width = width;
+ req->height = chunk_y;
+ memmove(GetReqData(req), pixels, size);
+ y += chunk_y;
+ pixels += width * chunk_y;
+ height -= chunk_y;
+ }
}
/*
* Read the color values from the specified rectangular area of the
* specified drawable into a supplied buffer. If the drawable is a
This patch chops the image into manageable pieces and displays them
one after the other using the standard GrArea protocol mechanisms.
We have had no trouble with it, but we wonder why it seems that the
GrReadArea don't have the same problem... We have not looked into
it - will do if someone likes the patch above (the patch is also
MIME attached with TABs intact).
This patch should actually be quite nice as it reduces the time that
the server is busy with a single client - which might improve response
times for other apps (more smooth operation).
The diff is against 0.87pre1.
- Morten
PS: Maybe chunk_y should be a long, just realised smaller systems
may run into trouble, although I can't see why at the momment.
[Content type application/octet-stream not shown. Download]
