| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 36.1 | To start the discussion... | LEOVAX::TREGGIARI | | Thu Jan 26 1989 18:32 | 19 |
| Well, just for the sake of discussion, how about:
1. Font units for text-based dialog boxes
2. No "large" dialog boxes (e.g. greater than 1/2 the size
of a 19" monitor screen)
3. A "world-coordinate" drawing widget (e.g. GKS widget)
for applications drawing graphics.
These don't help an application that is "iconic" rather than
text based. That is, they need to supply the "icons" in different
sizes.
What other problems don't these 3 techniques solve?
Leo
|
| 36.2 | No device independence w/o resolution independence... | IAGO::SCHOELLER | Who's on first? | Thu Jan 26 1989 18:55 | 25 |
| The session presented by the representative of Silicon Graphics really
pointed out the big problems. They are talking about approximately
19" monitors with 300dpi. The difference between a 1 pixel and a 3
pixel line is imperceptible. The visible features of applications which
dictate fonts or feature sizes in fixed pixels are impossible to recognize.
He pointed out applications which highlight a button by changing the window
border width from 1 to 3. It is an invisible change on his monitor.
We have applications which produce pushbuttons with bitmap labelling. These
have no ability to adapt to different server screens. Many resources in our
applications are hardwired to pixel sizes. Or are described in pixels by
.Xdefaults at the client so that there is no (or little) flexibility for
different servers.
Even the suggestions in .1 do not cover the situation in which the
screen characteristics are radically different than what we at DEC (and
in most of the X world) view as normal.
One possible approach would be a widget set with the feature size resources
being in points or some other physical size measure. Then the tool kit
would translate these into pixel units for communication with the server.
Dick
|
| 36.3 | But I thought... | POOL::HALLYB | The smart money was on Goliath | Mon Jan 30 1989 13:15 | 6 |
| Isn't it true that working with font units requires a call to the
server to determine the width of a string? Doesn't that make
programming more difficult and cost runtime performance?
John
|
| 36.4 | | LEOVAX::TREGGIARI | | Mon Jan 30 1989 14:49 | 26 |
| > Isn't it true that working with font units requires a call to the
> server to determine the width of a string? Doesn't that make
> programming more difficult and cost runtime performance?
No, using font units has nothing to do with asking the server
for the width of strings. The toolkit never asks the server,
it uses the Xlib routine that does the calculation on the client
side (this is done independently of the "units" setting).
The extra overhead of font-units is:
1. When the dialog box (or subclass of dialog box) is created
three font properties are fetched. This also happens if the
font is later XtSetValue'd.
2. When children are added, the FontX and FontY are multiplied by
a scale factor to determine the real x and y. This also happens
if the x and y are later XtSetValue'd.
I have not seen any performnce figures (and I have done a lot of
performance testing personally) that suggest that using font-units
is a significant overhead.
Leo
|