Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!apple!bloom-beacon!SUN.COM!tomj
From: tomj@SUN.COM (Tom Jacobs)
Newsgroups: comp.windows.x
Subject: Re: XView -- first experiences
Message-ID: <8910132223.AA14255@snowking.sun.com>
Date: 13 Oct 89 22:23:49 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 63


> 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