[Fwd: xorg Digest, Vol 35, Issue 128] | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
-------- Original-Nachricht -------- Betreff: xorg Digest, Vol 35, Issue 128 Datum: Mon, 30 Jun 2008 19:38:26 -0700 Von: xorg-request@xxxxxxxxxxxxxxxxxxxxx Antwort an: xorg@xxxxxxxxxxxxxxxxxxxxx An: xorg@xxxxxxxxxxxxxxxxxxxxx Send xorg mailing list submissions to xorg@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx You can reach the person managing the list at xorg-owner@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxx> Subject: Re: Further notes on 7.4 To: Daniel Stone <daniel@xxxxxxxxxxxxx>, Adam Jackson <ajax@xxxxxxxx>, xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <4869804B.7060108@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/xorg > ------------------------------ Message: 2 Date: Tue, 1 Jul 2008 01:59:48 +0100 From: Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> Subject: Re: Resolution indpendence To: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <18537.33156.846108.213669@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> ------------------------------ Message: 3 Date: Tue, 01 Jul 2008 03:05:31 +0200 From: Roland Scheidegger <sroland@xxxxxxxxxxxxxxxxxxxx> Subject: Re: Max resolution of Intel Graphics Chipsets To: Erwin Rol <mailinglists@xxxxxxxxxxxx> Cc: xorg <xorg@xxxxxxxxxxxxxxxxxxxxx> Message-ID: <486982DB.2070601@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> Subject: Re: Resolution indpendence Cc: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <18537.35295.302792.141261@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> ------------------------------ Message: 5 Date: Tue, 01 Jul 2008 02:36:19 +0100 From: David De La Harpe Golden <david.delaharpe.golden@xxxxxxxxx> Subject: Re: Resolution indpendence To: Steven J Newbury <steve@xxxxxxxxxxxxxxx> Cc: Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>, xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <48698A13.7030207@xxxxxxxxxxxxxx> 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@xxxxxxxx> Subject: Constant DPI regardless of resolution To: xorg@xxxxxxxxxxxxxxx Message-ID: <g4bvc6$ptv$1@xxxxxxxxxxxxx> 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@xxxxxxx> Subject: Re: Further notes on 7.4 To: Brian Paul <brian.paul@xxxxxxxxxxxxxxxxxxxx> Cc: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <486997A0.7000309@xxxxxxx> 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@xxxxxxx Sun Microsystems, Inc. - X Window System Engineering ------------------------------ Message: 8 Date: Mon, 30 Jun 2008 22:38:49 -0400 From: Felix Miata <mrmazda@xxxxxx> Subject: Re: Resolution indpendence To: xorg@xxxxxxxxxxxxxxxxxxxxx Message-ID: <486998B9.60202@xxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg End of xorg Digest, Vol 35, Issue 128 ************************************* _______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg
[X Forum] [Devices] [XFree86] [XFree86 Newbie] [Site Home] [IETF Annouce] [Security] [Fontconfig] [Bugtraq] [Rubini] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Video for Linux] [Linux RAID] [Linux Resources]