[Fwd: xorg Digest, Vol 35, Issue 128]
Regina
regina.apel at gmx.de
Thu Jul 3 02:32:45 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 35, Issue 128
Datum: Mon, 30 Jun 2008 19:38:26 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. Re: Further notes on 7.4 (Stuart Kreitman)
2. Re: Resolution indpendence (Glynn Clements)
3. Re: Max resolution of Intel Graphics Chipsets (Roland Scheidegger)
4. Re: Resolution indpendence (Glynn Clements)
5. Re: Resolution indpendence (David De La Harpe Golden)
6. Constant DPI regardless of resolution (Nikos Chantziaras)
7. Re: Further notes on 7.4 (Alan Coopersmith)
8. Re: Resolution indpendence (Felix Miata)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2008 17:54:35 -0700
From: Stuart Kreitman <Stuart.Kreitman at Sun.COM>
Subject: Re: Further notes on 7.4
To: Daniel Stone <daniel at fooishbar.org>, Adam Jackson <ajax at nwnk.net>,
xorg at lists.freedesktop.org
Message-ID: <4869804B.7060108 at sun.com>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
We built it and we use(d?) it in 2 projects. I'm asking around to see
if we still have consumers
of it, but at least one principal guy is on vacation atm.
Stuart K.
Daniel Stone wrote:
> On Mon, Jun 30, 2008 at 02:54:50PM -0400, Adam Jackson wrote:
>
>> In the same vein, I suspect XEvIE will either go away or be much changed
>> by 7.5.
>>
>
> If anyone still wants it around, they're going to have to make it work
> _properly_ with the new stuff, otherwise it's failing to exist.
>
> Cheers,
> Daniel
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
------------------------------
Message: 2
Date: Tue, 1 Jul 2008 01:59:48 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <18537.33156.846108.213669 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Steven J Newbury wrote:
> > > Going forward with SVG icons it's not going to be a problem. A "best" (user
> > > preference) solution can be applied for "legacy" software if necessary.
> > > Notice that Vista deals with all legacy applications by using the hardware
> > > scaler of the graphics card to provide 96dpi compatiblity.
> >
> > This only really works for larger icons. If you have a 48x48 icon,
> > anti-aliased re-scaling is likely to give adequate results at "large"
> > icon sizes. When you get down to the 16x16 icons used in the file
> > manager in list/detail view, it really needs to be hand-tuned to avoid
> > just being a coloured blob.
>
> If icon sizes need be that small then, absolutely, a hand-tuned bitmap
> is probably the only way to go. On a high DPI display such icons are
> larger than 16x16 though. Scaling down to very low DPI screens may be
> "good enough", how bad do you find the current SVG icon themes to be in
> such cases?
Which icons are SVG?
I don't use Gnome or KDE, or a graphical file manager, so about the
only icons I normally see are the stock OK/Cancel/Open/Save etc icons
in the few GTK+ programs which I use.
Mostly, I find that most GTK+ programs oversize everything (icons,
fonts, etc) by default (even after they've been told that the 125 dpi
screen is actually 75 dpi). I find XP's defaults on a 125 dpi screen
(i.e. tiny) to be adequate for normal use (desktop, file manager,
etc), although any heavy-duty text editing is done in XEmacs on Linux
(typically via Xming on the XP box, which needs its own monitor, and I
need desk space more than the Linux box needs a separate monitor).
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 3
Date: Tue, 01 Jul 2008 03:05:31 +0200
From: Roland Scheidegger <sroland at tungstengraphics.com>
Subject: Re: Max resolution of Intel Graphics Chipsets
To: Erwin Rol <mailinglists at erwinrol.com>
Cc: xorg <xorg at lists.freedesktop.org>
Message-ID: <486982DB.2070601 at tungstengraphics.com>
Content-Type: text/plain; charset=UTF-8
On 01.07.2008 01:55, Erwin Rol wrote:
> On Tue, 2008-07-01 at 01:26 +0200, Tomas Carnecky wrote:
>> Erwin Rol wrote:
>>> Hello all,
>>>
>>> I am looking for a solution where I can connect two TFT's of
>>> 1440x900, and display different images on those TFT's.
>>>
>>> Most Intel chipsets support two independent outputs, but it seems
>>> that the internal framebuffer is the limiting factor here. I
>>> would need 2880x900 or 1440x1800 (the layout is not important).
>>>
>>> For example, do I understand correct that for example the Intel
>>> 915 chipset does support two outputs of 1440x900 (or even
>>> larger), but that the internal framebuffer only can be 2048x1536?
>>>
>>>
>>> I checked several Intel chipsets and they all seem to be
>>> "limited" to 2048x1536. Are there Intel chipsets that can do for
>>> example 2048x2048, so it can fit a 1440x1800 resolution?
>> $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum
>> 4096 x 1440 ...
>>
>
> Weird the datasheet mentions a maximum resolution of ; - Supports
> flat panels up to 2048x1536 @ 60 Hz or digital CRT/HDTV at 1920x1080
> @ 85 Hz
That's not really "framebuffer" size just what the ramdac (in case of
analog) or single-link tmds is capable of.
> ?
>> This is on a i965 chip. But I'm sure the vertical resolution could
>> go much above the 1440. In any way, 2048x2048 is only the
>> limitation of the 3D engine, if you don't need OpenGL (compiz,
>> games etc), the limit is much higher. And i965 has the 3D limit at
>> 8192x8192, only older chips have the above mentioned 2048x2048.
>>
>> tom
>
> Is the some list somewhere with what the Intel Graphic chips can and
> can not do ? Like maximum 2D/3D/video-overlay resolution, maximum
> framebuffer size, etc. ?
Older (and some not so old) intel chips (everything up to gen 3.5, i.e.
not gen4 (i965) based can do 2kx2k for 3d (both textures and drawing
rectangle), and gen4 can do 8kx8k (textures and drawing rect). According
to the comments in i830_exa.c all these chips can do 2d operations to
larger resolutions than you'd care (32kx64k - I think you had some
trouble allocating enough ram for this :-)).
Textured video source size is obviously limited to what the 3d texture
size is (but driver limited to 2048x2048), overlay source video size
would be 2048x2048 (i915 and newer) but driver limits this to 1920x1088
due to allocation problems.
Roland
------------------------------
Message: 4
Date: Tue, 1 Jul 2008 02:35:27 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
Cc: xorg at lists.freedesktop.org
Message-ID: <18537.35295.302792.141261 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Felix Miata wrote:
> > Windows' icon sizes are: 16x16, 24x24, 32x32, 48x48. The first two are
> > "small" icons for use in "list" and "detail" views, the last two are
> > "large" icons for "icon" view, desktop, start menu etc. In each case,
> > the larger version is 50% larger than the smaller version, whereas the
> > difference between 1024x768 and 1280x960 is 25%. It's not like fonts,
> > where they typically provide bitmaps at 2pt increments.
>
> Sounds to me like you're using the same bogus math as typesetters and web
> deeziners use. 8px is not half the size of 16px - it's 25%, length times
> width. Size is area, not one single dimension. A 1600x1200 display has 4
> times as many logical px (1,920,000) as an 800x600 display (480,000). Thus, a
> 48x48 icon has 2304px, 2.25 times the 1024px of a 32x32 icon; 4 times as many
> as a 24x24 (576).
I think you missed my point, because using areas only makes the issue
more pronounced.
My point is that you need small enough increments that you can always
get roughly the size that you want, rather than being stuck with a
choice between definitely too large or definitely too small.
With fonts, you get that choice. But the interval between the
available icon sizes is much larger.
> > The 96 dpi figure was just an arbitrary value, chosen so that various
> > common point sizes (6, 8, 12, 16) would work out to an integer number
> > of pixels.
>
> It's arbitrary all right, but not necessarily for the reason you claim. e.g.
> at 96 DPI:
>
> 6pt = 8.000px^~1.5 (not enough px per character box for all complete
> character sets to be rendered intelligibly)
> 8pt = 10.667px^~1.5
> 10pt = 13.333px^~1.5
> 12pt = 16.000px^~1.5
> 16pt = 21.333px^~1.5
I have no idea what you're getting at here.
> The reason anyone else uses it is because M$ uses/used it, and the reason for
> that misfortunate legacy is explained on:
> http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx
That's interesting, but it doesn't really have any bearing on the
notion of resolution independence.
So long as display resolutions remain low enough that you have UI
elements which are only a few pixels in size, the fact that you
ultimately have to rasterise whole pixels means that you can't just
operate entirely in physical units, in the same way that you can with
a 300+dpi laser printer.
Well, you *can*, but the artifacts are going to look a lot worse.
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 5
Date: Tue, 01 Jul 2008 02:36:19 +0100
From: David De La Harpe Golden <david.delaharpe.golden at gmail.com>
Subject: Re: Resolution indpendence
To: Steven J Newbury <steve at snewbury.org.uk>
Cc: Glynn Clements <glynn at gclements.plus.com>,
xorg at lists.freedesktop.org
Message-ID: <48698A13.7030207 at googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Steven J Newbury wrote:
> If icon sizes need be that small then, absolutely, a hand-tuned bitmap
> is probably the only way to go. On a high DPI display such icons are
> larger than 16x16 though. Scaling down to very low DPI screens may be
> "good enough"
I'd say that would depend on the how "busy" the vector icon is and the
quality of the renderer. It's certainly _possible_
to design vector icons that look good even drawn at 16x16 (particularly
given both ordered-subpixel rendering/display and sub-pixel positioning
and antialiasing in the renderer).
(also don't forget that the "svg" icon themes tend to bundle prerendered
and potentially hand-tweaked bitmaps for small pixel sizes like 16x16
- of course, unlike fonts, vector icons don't tend to be hinted AFAIK.
Hmm. I guess they could be autohinted to some extent, or, heh, some
color-outline-font format supporting manual hinting used for them :-) )
------------------------------
Message: 6
Date: Tue, 01 Jul 2008 03:56:33 +0300
From: Nikos Chantziaras <realnc at arcor.de>
Subject: Constant DPI regardless of resolution
To: xorg at freedesktop.org
Message-ID: <g4bvc6$ptv$1 at ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
After RTFM and Google, I can't seem to find a way to force xorg to use a
constant DPI value regardless of the current resolution. It calculates
the DPI with the known formula (screen dimensions and resolution). But
in my case, when changing resolution, the DFP (digital flat panel) is
set-up to simply keep the picture centered, with black borders around it
if the resolution is smaller than the DFP's native resolution. The DPI
does not change (only the resolution changes.)
Starting X with "-dpi 86" also won't help; the DPI still changes after
switching resolution (starting in 1024x768 and then going 1280x1024 for
example results in huge fonts). The desktop's environment (KDE in this
case) "Force 96DPI" is sub-optimal; my DFP is not 96DPI.
This is also an issue when running xorg in a virtual machine (the VM
window for example is 1024x768 while the monitor is running at
1280x1024). Resizing the window changes the resolution but
unfortunately xorg also changes DPI even though it shouldn't.
If there is a way, how can I force a constant DPI regardless of resolution?
------------------------------
Message: 7
Date: Mon, 30 Jun 2008 19:34:08 -0700
From: Alan Coopersmith <Alan.Coopersmith at Sun.COM>
Subject: Re: Further notes on 7.4
To: Brian Paul <brian.paul at tungstengraphics.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <486997A0.7000309 at sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Brian Paul wrote:
> I don't recall other C compilers having a dependency generator option
> like gcc.
Sun cc does - we had a script form of makedepend that wrapped it in the past,
much like the old gccmakedep script.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
------------------------------
Message: 8
Date: Mon, 30 Jun 2008 22:38:49 -0400
From: Felix Miata <mrmazda at ij.net>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <486998B9.60202 at ij.net>
Content-Type: text/plain; charset=ISO-8859-1
On 2008/07/01 02:35 (GMT+0100) Glynn Clements apparently typed:
> Felix Miata wrote:
>> Sounds to me like you're using the same bogus math as typesetters and web
>> deeziners use. 8px is not half the size of 16px - it's 25%, length times
>> width. Size is area, not one single dimension. A 1600x1200 display has 4
>> times as many logical px (1,920,000) as an 800x600 display (480,000). Thus, a
>> 48x48 icon has 2304px, 2.25 times the 1024px of a 32x32 icon; 4 times as many
>> as a 24x24 (576).
> I think you missed my point, because using areas only makes the issue
> more pronounced.
Area doesn't make it any more or less pronounced. What it should make more
pronounced is the ability to recognize the disparities discussed. The
minimization of real differences into artificially smaller differences makes
the problems _look_ like smaller problems than they really are.
> My point is that you need small enough increments that you can always
> get roughly the size that you want, rather than being stuck with a
> choice between definitely too large or definitely too small.
Or use something intended to scale in the first place.
AFAICT, the technology exists for displays to be double or more the
resolution the average user has now, but the systems they're expected to be
used with are dependent on anachronisms like 96 DPI, choices between two tiny
bitmap icon size groups, and apps designed as if they were intended for print
media of fixed dimension instead of computer display screens of widely
varying size and resolution. Few would now buy those much higher resolutions
due to the tininess of objects that would result from their use encumbered by
those legacies. If the desktops could accommodate the same resolution laser
printers started with (300 or more), the increments would be too small to
matter, and scaling would bother few, or maybe no one.
> With fonts, you get that choice. But the interval between the
> available icon sizes is much larger.
As long as everyone is stuck with a tiny selection of bitmap images, that's
exactly right. It's well past time for everyone to remain stuck with them though.
>> > The 96 dpi figure was just an arbitrary value, chosen so that various
>> > common point sizes (6, 8, 12, 16) would work out to an integer number
>> > of pixels.
>> It's arbitrary all right, but not necessarily for the reason you claim. e.g.
>> at 96 DPI:
>> 6pt = 8.000px^~1.5 (not enough px per character box for all complete
>> character sets to be rendered intelligibly)
>> 8pt = 10.667px^~1.5
>> 10pt = 13.333px^~1.5
>> 12pt = 16.000px^~1.5
>> 16pt = 21.333px^~1.5
> I have no idea what you're getting at here.
You mentioned integer text sizes as a reason why 96 DPI. Few above calculate
to integers. e.g. I meant 13.333^1.5 as a character box of about 13.333 tall
by about half that width for a total of about 88.89px available per 10pt
character.
>> The reason anyone else uses it is because M$ uses/used it, and the reason for
>> that misfortunate legacy is explained on:
>> http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx
> That's interesting, but it doesn't really have any bearing on the
> notion of resolution independence.
Just tried to correct any misconception about the source of legacy.
> So long as display resolutions remain low enough that you have UI
> elements which are only a few pixels in size, the fact that you
> ultimately have to rasterise whole pixels means that you can't just
> operate entirely in physical units, in the same way that you can with
> a 300+dpi laser printer.
Right, so desktop environments need to make some big changes to permit
display devices with enough resolution to be feasible. So, this thread isn't
so much about whether people know the conflicts exist so much as it is the
posture of those trying to make the best of what is vs. those trying to push
capabilities up to a reasonable ought-to-be. I doubt anyone would complain if
the average was 300. The problems are many in dealing with the gap between
current reality and goodness, how to eliminate that gap, and living with and
minimizing the pain of the under construction mess in the meantime.
> Well, you *can*, but the artifacts are going to look a lot worse.
Maybe to people with your 15/15 vision, but less likely to people corrected
to no better than 25/25. I generally find a native size image no better or
worse than that same image blown up to 4X its native size when its native
size is only 1/4 big enough to be useful anyway. I'm a user of high
resolution in order to gain quality, not interested in stuffing more things
of smaller size into a given space.
I'm all for getting everything beyond bitmaps ASAP. Puters are plenty
powerful. Let's get them using that power to make people happy users instead
of bickering finger pointers.
--
"Where were you when I laid the earth's
foundation?" Matthew 7:12 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 35, Issue 128
*************************************
More information about the xorg
mailing list