| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2474.1 | | MU::PORTER | bliss is ignorance | Mon Mar 19 1990 22:08 | 16 |
| Sounds like a bit-order-within-the-byte problem!
I believe, but I don't have my X bible at hand, that in the
specific case of images, the client is reponsible for
delivering the bit order that the server needs. (The
hardware defines whether it displays low-bit-first or
high-bit-first, and the server passes the image unchanged
to the hardware; the argument was "efficiency").
This translates into "if your application code doesn't
support big-endian formats you're out of luck".
This at least is the way I remember it working, but
it's been a while since I looked.
|
| 2474.2 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Tue Mar 20 1990 10:32 | 6 |
|
.1 ... if it really is the clients problem, then isn't it Xlib's
responsibility then to reverse the bits? Surely the actual
application should'nt need to worry about big/little-endian
problems.
|
| 2474.3 | Is it fixable? | TOWNS::SWEATT | | Tue Mar 20 1990 11:31 | 9 |
|
Geez, it didn't take long for this topic to go over my head. My
apologies, but I am not familiar enough with the bit level internals of
X. From a user standpoint, do you know who is responsible? Should DEC
be attempting a fix? Has an SPR been written? Any ideas how to fix
the problem? Thanks again.
Bill
|
| 2474.4 | QAR problem against DECwrite | STAR::VATNE | Peter Vatne, VMS Development | Tue Mar 20 1990 13:25 | 10 |
| Any problems with displaying images on another vendor's server should
be QARed against the particular application. Although this might possibly
be a problem in the other vendor's server, since it happens with both IBM
and Apollo, I would bet the problem is on our end. If the DECwrite folks
have to pass the buck to someone else, let them do it.
Don't worry about whether someone else has filed an SPR. Your case might
be different from someone else's problem that sounds similar. Even if it
is the exact same problem, your example might be the one that makes it
possible for the developer to solve the problem.
|
| 2474.5 | | GERUND::WOLFE | Three dimensional programming on a 2-D screen | Tue Mar 20 1990 18:11 | 3 |
| This is a DECwrite bug. It's on the list of things to be fixed for our
V1.1....
Pete
|
| 2474.6 | | MU::PORTER | bliss is ignorance | Tue Mar 20 1990 23:09 | 5 |
| re .2
No. [don't shoot me, I'm only the messenger].
|
| 2474.7 | What is this one? | DECWIN::FISHER | Prune Juice: A Warrior's Drink! | Wed Mar 21 1990 17:14 | 13 |
| Just out of curiosity, and also to set the record straight:
In the Ximage data structure, you tell Xlib the endianness of your
image. When you do a PutImage, Xlib compares the image info with what
the server wants, and swaps it if it is different. Thus applications
that don't lie to xlib should not be concerned about opposite
endianness.
Is this the DECwrite problem? Are you just filling in the data
structure different from what the data actually is? Is there something
else that other application writers should be careful of?
Burns
|
| 2474.8 | Ultrix Globe Demo also Errs | TOWNS::SWEATT | | Wed Mar 21 1990 20:12 | 8 |
|
By the way, I've noticed the same behavior with the globe demo on
Ultrix. I suppose I should consult the DECwrite notes forum, but does
anybody know more about DECwrite 1.1? What is being fixed/enhanced,
when will it be released, stuff like that.
Thanks alot for your help.
Bill
|