[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
Moderator: | STAR::VATNE |
|
Created: | Mon Oct 30 1989 |
Last Modified: | Mon Dec 31 1990 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 3726 |
Total number of notes: | 19516 |
2065.0. "Any one need an Area fill routine... Problem with XGetImage()." by WPOMM2::ZAMBOTTI () Wed Jan 17 1990 23:43
Hi people,
this note carries on from 2045.7.
I've finished coding and debugging the fill() routine. This is a simple routine
that only works on convex areas. I'm debugging the flood routine now which works
on any area.
Although the code works, there seems to be a performance problem with the
XGetImage() function. From the time this single command is executed to the time
it finishes 69 seconds have elapsed. And this is before my own fill code
starts to execute. The size of the area I am getting is 640 by 350 and I can
only assume that the larger the size the longer it would take.
During this time (69 secs) DECwindows cannot be used at all.
Can this be considered a serious performance overhead or have I inadvertantly
bugged up the code.
Anyway here follows the code could somebody please verify the execution speed
and logic/syntax and get back to me on this.
/*
Fills a convex bordered region with the current foreground color. Fill
starts its fill at the specified X, Y coordinate and fills all pixels of
the same color as the first pixel (@ X, Y).
As this routine uses XDrawLine to paint the area all the GC components of
XDrawLine can be set and used.
*/
void fill(Disp, Win, X, Y)
Display *Disp ;
Window Win ;
int X, Y ;
{
Window RootWin ;
XImage *FillImage ;
int X1, X2, PointX, PointY, Width, Height, XPos, YPos, Border, Depth ;
unsigned long ReferencePixel ;
XGetGeometry(Disp, Win, &RootWin, &XPos, &YPos, &Width, &Height, &Border, &Depth) ;
FillImage = XGetImage(Disp, Win, 0, 0, Width, Height, AllPlanes, XYPixmap) ;
ReferencePixel = XGetPixel(FillImage, X, Y) ;
for(PointY = Y ; PointY < Height && XGetPixel(FillImage, X, PointY) == ReferencePixel ; PointY++) {
for(X1 = X-1 ; X1 && XGetPixel(FillImage, X1, PointY) == ReferencePixel ; X1--) ;
for(X2 = X ; X2 < Width && XGetPixel(FillImage, X2, PointY) == ReferencePixel ; X2++) ;
XDrawLine(Disp, Win, GCID, X1+1, PointY, X2-1, PointY) ;
}
for(PointY = Y-1 ; PointY && XGetPixel(FillImage, X, PointY) == ReferencePixel ; PointY--) {
for(X1 = X-1 ; X1 && XGetPixel(FillImage, X1, PointY) == ReferencePixel ; X1--) ;
for(X2 = X ; X2 < Width && XGetPixel(FillImage, X2, PointY) == ReferencePixel ; X2++) ;
XDrawLine(Disp, Win1, GCID, X1+1, PointY, X2-1, PointY) ;
}
XDestroyImage(FillImage) ;
}
T.R | Title | User | Personal Name | Date | Lines |
---|
2065.1 | | WPOMM2::ZAMBOTTI | | Thu Jan 18 1990 04:08 | 28 |
| Typo one :
The First typo is in the function definition it should read :
void fill(Disp, Win, GCID, X, Y)
Display *Disp ;
Window Win ;
GC GCID ;
int X, Y ;
Sorry GCID was a global in my code.
Typo two :
The second XDrawLine line which reads :
XDrawLine(Disp, Win1, GCID, X1+1, PointY, X2-1, PointY) ;
should read
XDrawLine(Disp, Win, GCID, X1+1, PointY, X2-1, PointY) ;
as there is no Win1 variable declared.
Regards,
Author.
|
2065.2 | XGetImage performance problem info request | STAR::BMATTHEWS | | Thu Jan 18 1990 09:11 | 1 |
| What is your configuration? What version are you running? Which OS? - Bill
|
2065.3 | Info request response! | WPOMM2::ZAMBOTTI | | Thu Jan 18 1990 20:23 | 19 |
| Hardware :
DECstation 2100
20 Mb Memory
RZ55
RZ23
TK50
Software :
ULTRIX WS V2.0 (RISC) & U-32 V3.1/UWS V2.1 (RISC) UPD
DECnet-ULTRIX V3.1a
P.S.
Still dont think any function should disable my machine and have you seen the
note 2066.
Walter.
|
2065.4 | insights... | GSRC::WEST | Variables don't, Constants aren't | Fri Jan 19 1990 10:34 | 16 |
|
I believe XGetImage uses XGrabServer which disables processing of requests
and close downs on all other connections than the one this request was made
from. This is why you are unable to do anything else.
I do an XGetImage on a Firefox for a print screen program and it only takes
about a second or two to get the image. I do not know much about the video
hardware you are using and so I'm not sure how the XGetImage is implemented.
This call reads the frame buffer and puts the data into a data structure
for your client to access. It would appear that reading the frame buffer is
where alot of the time is spent and I do not have any help in making it
faster. Maybe someone else out there might be able to help in this area.
-=> Jim <=-
|
2065.5 | The real answer to the problem! | WPOMM2::ZAMBOTTI | | Wed Jan 24 1990 03:45 | 18 |
| Hi people,
I've managed to discover the bug in my code that caused the seventy second
delay.
Just change all references of "XYPixmap" to "ZPixmap" and everything should be
ok. This is because our PMAX hardware is ZPixmap orientated and the XGetImage()
function had to perform a conversion between one and the other.
There is also a flood routine in note 2067 that has the same problem and the
above fix will work in that as well.
There is also a new version of the flood routine in note 2067 which is very
much faster.
The author,
Walter Zambotti.
|
2065.6 | Well, I'll be dipped :-) | VMSDEV::BALLOU | It's not slow, it's careful! | Sat Feb 03 1990 15:47 | 16 |
| I'd like to reopen this topic and ask a simple question (mostly to make
sure I have my facts straight). I just tried a test of calling
XGetImage on a 200x200 rectangle with both XYPixmap and ZPixmap format.
(This was on a VS2000/GPX with the MIT X11R4 server under ULTRIX.)
With XYPixmap, the operation took 2 minutes 25 seconds, while with
ZPixmap format, it required less than 5 seconds. Now I understand what
has been happening when I have (falsely) accused various servers of
getting stuck in an infinite loop ...
Anyway, here's my question. My understanding is that it is not
possible for a client to query a server and determine whether XYPixmap
format or ZPixmap format is preferable, or whether there is indeed a
preference. Is this true? If so, wouldn't it be a useful addition to
the X11 standard?
- Ken
|