carlson@lance.tis.llnl.gov (John Carlson) (10/13/89)
I started porting a ~15,000 line application to XView a couple of days ago. The full conversion routines worked fairly well. I found myself using all portions of the API and conversion manuals. Some canvases aren't drawn on. I assume I should write on the canvas paint window or create REPAINT_PROCs. When I use a DS3100 for a server (both app and olwm on a Sun), more of the canvases don't get drawn on. pw_text and pw_vector don't work on one canvas where they had on the Sun server. Resizing a window in olwm caused the machine (or at least the X server) to crash (!). What are the xv_set/xv_get warnings (not an object [?]), and how do I get rid of them? John Carlson carlson@tis.llnl.gov
tomj@SUN.COM (Tom Jacobs) (10/14/89)
> I started porting a ~15,000 line application to XView a couple of days > ago. The full conversion routines worked fairly well. I found > myself using all portions of the API and conversion manuals. > > Some canvases aren't drawn on. I assume I should > write on the canvas paint window or create REPAINT_PROCs. Yes, you should only paint into the canvas's paint window(s) through your CANVAS_REPAINT_PROC or CANVAS_RESIZE_PROC. After creating the canvas window (which is actually a "view" management wrapper) you get the paint window (canvas_paint_window) and paint into that window. You should set cursors and inputmasks on this window too. > When I use a DS3100 for a server (both app and olwm on a Sun), more of the > canvases don't get drawn on. pw_text and pw_vector don't work on > one canvas where they had on the Sun server. The problem you're experiencing with the SunView Pixwin compatibility functions is that the behavior of the PIX_SRC|PIX_DST operation is not proper on machines with reversed foreground and background pixel values (such as the 3100 and the NCD, among others). On machines with reversed foreground and background, because the foreground is 0, PIX_SRC|PIX_DST causes all drawing to be invisible. A work-around (within the XView library) would be to draw into a 1 bit deep pixmap then copy that pixmap into place. However, as this sounds, it is *very* slow and expensive and we're not sure how long we want to carry the Pixwin interface (we *highly recommend redoing your pixwin graphics with Xlib graphics). I would suggest converting your pw_* graphics calls to the Xlib graphics directly. This will bypass the the inconsistencies of the Pixwin graphics model and increase your graphics performance (since the pw_ calls must be translated into Xlib calls anyway). I'll post a guide to converting your pw_*() calls to Xlib in the next couple of days (need to make it pretty first :-). When you find any bugs like this, please feel free to post them to xviewbugs@sun.com (...!sun!xviewbugs) and we'll help you out. > Resizing a window in olwm caused > the machine (or at least the X server) to crash (!). Do you have a stack trace? Is this repeatable? Please send whatever you know to xviewbugs. Thanks! > What are the xv_set/xv_get warnings (not an object [?]), and how > do I get rid of them? You'll get these warnings if you try to object that aren't really objects (eg. NULL) or if you try to call get/set with a value returned from another get without checking its value... these warning are pretty easy to fix if you step through the program under dbx and then evaluate the preceeding code to see what you're doing wrong. If you can zero-in on the surrounding code, I'm sure we can point-out the problem quickly. > John Carlson > carlson@tis.llnl.gov Tom Jacobs (tomj@sun.com -OR- ...!sun!tomj) Sun Microsystems, Inc. Mountain View, CA 94943
tomj@SUN.COM (Tom Jacobs) (10/14/89)
I just thought I should clarify something I wrote... > On Oct 13, 3:23pm, Tom Jacobs wrote: > Yes, you should only paint into the canvas's paint window(s) through > your CANVAS_REPAINT_PROC or CANVAS_RESIZE_PROC. After creating the I would suggest against doing *any* painting from the CANVAS_RESIZE_PROC because in the case of a resize, there will "almost" always be a corresponding call to the CANVAS_REPAINT_PROC. Because of that, more graphics calls would be called than is necessary. I say "almost" because with the "improper" setting of window gravity attributes, canvas resize attributes or retainedness may cause the resize proc to be called without a corresponding repaint call. However, in all of my experiements with this issue, I find problems in which the canvas is not properly repainted as I expected it. The shot to all of this is that resize procs should probably not do repainting but simply acknowledge the size changes if necessary and let the repaint proc get called normally. Tom Jacobs (tomj@sun.com -OR- ...!sun!tomj) Sun Microsystems, Inc. Mountain View, CA 94943