GNOME Bugzilla – Bug 546711
units and resolution independence
Last modified: 2014-08-23 05:59:18 UTC
See http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00044.html for the background and details. Will attach the patch here for review.
Created attachment 116020 [details] [review] latest patch against gtk+ trunk Compared to the email, all API docs are now completed; see http://people.freedesktop.org/~david/gtk-ri-patches/gtk/ http://people.freedesktop.org/~david/gtk-ri-patches/gdk/gdk-Units.html for details. Patch is against r21028 (trunk just a few minutes ago).
This is a dupe of bug 101859
I tried running GTK+ with this patch for my whole desktop session. Everything works fine. Even with forcing units on. That is... until I started evolution. Turns out this is the culprit http://svn.gnome.org/viewvc/evolution/trunk/widgets/misc/e-task-bar.c?revision=35826&view=markup /* Hah hah. GTK+ sucks. This is adapted from `gtkhbox.c'. */ child_info = g_new (GtkBoxChild, 1); child_info->widget = GTK_WIDGET (task_widget); child_info->padding = 0; child_info->expand = TRUE; child_info->fill = TRUE; child_info->pack = GTK_PACK_START; box = GTK_BOX (task_bar->priv->hbox); box->children = g_list_prepend (box->children, child_info); Awesome. Evolution sucks. As much as I'd like to scream "buggy app!" the right answer is to make GTK+ cope with evil stuff like that. The fix here is probably to keep a hash table from public childs to private childs rather than keeping two lists in sync. Shouldn't be hard and the code would probably even turn out to be a bit simpler. I wonder if the duplicity we do in GtkTable needs similar treatment...
Created attachment 116196 [details] [review] updated patch 157 files changed, 5898 insertions(+), 1807 deletions(-)
Changes from last patch - Rename Unit to Size and move it into the GTK name space - Use functions, not macros - All new API etc. is now documented http://people.freedesktop.org/~david/gtk-ri-patches/gtk/ http://people.freedesktop.org/~david/gtk-ri-patches/gtk/gtk-Units.html - When converting to pixels a GdkScreen and coordinates so we can find the right monitor - Fix the issue pointed out in comment 3. Also fix it for GtkTable. Pending 1. Fix multihead bugs where we need a widget to convert to pixel sizes - 'grep "user_widget =" gtk/*.c' will show where this is needed 2. Right now gtk_size_to_pixel() don't use the (x,y) coordinate pair passed in. We need some GtkSettings changes there 3. Don't concretely know yet what to do with GdkPixbuf usage in tree views and combo boxes. It's only a problem when the unit changes and that happens rarely. Suggestions welcomes. 4. Need to write a porting guide. Items 1-3 can probably be fixed post-merge. Item 4 is pretty easy. I also think the API is about right. So in order words please go ahead and review the patch in it's entirety - thanks ;-)
Also, this following needs fixing - the gtkrc parser; right now !0.5 can be used to specify em's. Don't know if that's good enough - the internal storage format for GtkSize needs to be reworked - technically we can change that at any point given that the binary layout depends on the runtime setting specifying whether RI is enabled or not - gtk_size_from_string() needs to be implemented
Created attachment 116308 [details] [review] updated patch New patch. And a new demo movie! http://people.freedesktop.org/~david/gtk-ri-2.ogg Docs with the changes in the patch here http://people.freedesktop.org/~david/gtk-ri-patches/gtk/ http://people.freedesktop.org/~david/gtk-ri-patches/gdk/ http://people.freedesktop.org/~david/gtk-ri-patches/gtk/gtk-Units.html generated using a tweaked gtk-doc. Changes from the patch in comment 5 - monitors can have different resolution so add new method gdk_screen_get_resolution_for_monitor(). Also the font options can certainly differ per monitor (e.g. subpixel order etc.) - while desktop environments like GNOME may or may not provide a way to tweak DPI per monitor (may decide to just default to 96 DPI and have only a way to tweak the global DPI. I don't know), I take it as a given that we need to support it at the API level. - thoughts? - provide gtk_icon_size_lookup_for_settings_for_monitor() since gtk_icon_size_lookup_for_settings() is broken as it doesn't take a monitor. - should we deprecate it? - Most GdkPixbuf usage isn't a problem; it's only a problem when you pass a real pixbuf instead of e.g. stock-id, icon-name, gicon etc. I've added an example in gtk-demo's assistant.c on how to catch the ::unit-changed signal and recompute the pixbufs. - gtk_size_to_pixel now takes a monitor number instead of coordinates - mostly for performance reasons; it's also nicer api - provide a ::unit-changed(int monitor_num) signal on GtkSettings (the previous patch had a :pixels-per-em property). Make mapped GtkWindows catch this signal and propagate ::unit-changed on all widgets in the window - track what monitor a window belongs to; provide convenience api gtk_widget_get_monitor_num(); new signal ::monitor-changed on GtkWindow. Also, on ::monitor-changed, propagate ::unit-changed on the window as well - Hey presto, now a window changes it's units when you move it to another monitor if the DPI differs - with gtk_widget_get_monitor_num(), make the rest of GTK+ use the safer _with_monitor() functions on GDK - fix all multihead bugs mentioned in comment 5 - A good test rig for testing this is to use a multi monitor setup and hack gdk_screen_get_resolution() to tripple the DPI for one of the monitors. I've left that code in the patch (although #ifdef'ed out). Here's an Ogg movie showing this http://people.freedesktop.org/~david/gtk-ri-2.ogg along with how well RI works right now. Still pending - Need to write a porting guide - the gtkrc parser; right now !0.5 can be used to specify em's. Don't know if that's good enough - the internal storage format for GtkSize needs to be reworked - technically we can change that at any point given that the binary layout depends on the runtime setting specifying whether RI is enabled or not - this is pretty trivial - gtk_size_from_string() needs to be implemented - maybe we don't want this
http://people.freedesktop.org/~david/gtk-ri-patches/gtk/gtk-Units.html now contains the beginnings of a guide on how to port apps.
Btw, it would probably be a good thing if GtkBox, GtkTable and perhaps others would use floating point math to lay out the children while still aligning them to pixel boundaries. We don't currently do that - we just clamp spacing to an integer before laying out items. Hmm....
Created attachment 116395 [details] [review] updated patch New patch - update to trunk (revision 21082) - evict entries in the icon cache when units change - add a new "Resolution Independence" window to gtk-demo - with a dpi slider - very useful for verifying that all widgets behave correctly when RI is enabled - rename gtk_size_enable_resolution_independence() to gtk_enable_resolution_independence() - invalidate layout in GtkScale on unit-change - the text above the slider didn't change size - rework gtksize.c and properly define the storage format - add new physical unit: mm - the maemo developers came up with a compelling use case at gtk-devel-list - improve the docs - in particular write up a porting guide - add GTK_SIZE_MAXPIXEL macro - turns out GtkToolbar needed that for the max-child-expand style property (it was using G_MAXINT previously) - drop gtk_size_from_string - also point out that the output of gtk_size_to_string may change at any time - add gtk_size_get_em(), gtk_size_get_mm() functions - using these, gtk_size_get_unit() and the GtkSize constructors, an application can now serialize stuff itself Docs updated too http://people.freedesktop.org/~david/gtk-ri-patches/gdk/ http://people.freedesktop.org/~david/gtk-ri-patches/gtk/ http://people.freedesktop.org/~david/gtk-ri-patches/gtk/gtk-Units.html I'm not going to do any more work on this until the patch is reviewed / merged since I consider the feature pretty much to be working now.. - the stuff in comment 9 would be interesting to implement but AFAICT it's not going to change a lot. Anyway, feedback more than welcome. And do let me know if there's anything I can do to make reviewing this stuff easier. Thanks.
I've split the patch into 20 smaller patches http://gitweb.freedesktop.org/?p=users/david/gtk%2B.git;a=shortlog;h=resolution-independence so it's easier to review. I've made sure that the tree compiles and works after every commit. Also, if this should ever go into mainline it's better to commit this in many small chunks to one can use git bisect for bug hunting etc. etc. The only change from the patch in the previous comment is a bugfix; GTK_SIZE_MAXPIXEL had some issues. This is now fixed. I'll probably be rebasing the branch from time to time to avoid this patch bitrotting away.
(In reply to comment #7) > - monitors can have different resolution so add new method > gdk_screen_get_resolution_for_monitor(). Also the font options > can certainly differ per monitor (e.g. subpixel order etc.) > - while desktop environments like GNOME may or may not provide a way > to tweak DPI per monitor (may decide to just default to 96 DPI and > have only a way to tweak the global DPI. I don't know), I take it > as a given that we need to support it at the API level. > > - thoughts? Seems like the only reasonable way to approach this to me. I agree it might be that the primary interface isn't suddenly overthrown but it needs to supported. And *then* once API is in place, the interfaces can be enhanced. > - provide gtk_icon_size_lookup_for_settings_for_monitor() since > gtk_icon_size_lookup_for_settings() is broken as it doesn't take > a monitor. > - should we deprecate it? That looks a little awkward to me. Could instead GtkSettings* be modified so that every monitor has its own settings? Then we can avoid making the API clumsy to use.
I was also thinking along those lines... Can't we create one GdkScreen per monitor now that X has started sharing a Screen for multiple monitors? That's really how it is supposed to be...
> I was also thinking along those lines... Can't we create one GdkScreen per > monitor now that X has started sharing a Screen for multiple monitors? That's > really how it is supposed to be... No, not really. The X model is that a screen is really defined by sharing a common visual. The only reason to ever have more than one X screen is if you don't have a common visual, e.g. a b/w monitor and a color one. GtkSettings should not really be per-monitor anyway. 95% are really just global settings. Only a select few things depend on the individual monitor, such as dpi or subpixel ordering.
On IRC it was proposed to test the patch against major consumers of GTK+ internals; just pasting it here so I don't forget <walters> davidz: i would test SWT, Qt (with gtk-qt-style) and OpenJDK at least too, some other major consumers of GTK+ internals <jdahlin> acrobat, flash and of course firefox, thunderbird etc. which was mentioned earlier in conversation. Also OpenOffice. (FWIW, I've tested the patch with Firefox, Flash and OpenOffice already and it works fine. As well as the rest of my GNOME 2.23 desktop on Fedora Rawhide.)
Leave out gtk-qt, though. No point in testing something that is a bad idea to begin with.
Has this been merged in? This is a major improvement and the patch is huge so it might be difficult to sync it regularly. Is anything important has been particularly broken with this patch?
(In reply to comment #17) > Has this been merged in? obviously, no. otherwise the bug would have been closed. > This is a major improvement and the patch is huge so it might be difficult to > sync it regularly. Is anything important has been particularly broken with this > patch? it needs proper review and testing with applications like firefox, eclipse and openoffice.
FWIW: this branch is on git.gnome.org nowadays: http://git.gnome.org/cgit/gtk+/log/?h=resolution-independence
punting to 3.0
(In reply to comment #20) > punting to 3.0 Sorry, what's the meaning of that expression? Does it mean RI is being pushed to 3.0 or being postponed? I couldn't find a proper translation (I'm Spanish).
Aleve: Postponed.
Oh, well, thanks. That's sad. I guess no RI for a couple more years. I so wished Gnome was first with this. At this pace, both Apple and MS will have it here sooner than us. :(
Not a helpful comment, technically speaking. Also, GTK 3.0 is planned for the next months.
There we go again. Linux and its technical elitism. Whatever. :( :(
So, I did some cleanup to the old "resolution-independence" branch (as it was really hard to diff against upstream GTK+ due to lots of merges). The result is uploaded here: http://github.com/garnacho/gtk/tree/new-ri-2-20 I plan to rebase this to GTK+ 3.0 once the major rendering-related changes are in there.
High ppi monitors are here finally. The new Macbook Pro sports a 220 ppi screen and several Ultrabooks have similar pixel density. OS X will support hi-ppi screens properly, of course, but it seems Windows 8 will also support a high degree of RI. So has this been postponed long enough or is the GNOME team willing to postpone it even further? Just curious.
The GNOME team has worked long and hard on postponing this feature. I don't think GNOME wants to change its position here just because Apple decides something is important. On the other hand, GNOME has always been a Windows clone, so Windows seeming to do it seems like a good reason for the GNOME people to seem interested in it. So I don't know really. I could try to ask the team, but I think they're a very secret council and only very rarely hold audiences. Maybe somebody here knows how to contact them?
Benjamin, I think you are misinformed, confused, and don't know what you are talking about. Since GNOME3 the GNOME team has decided to clone Apples instead of Windows, so I think that's enough reason for GNOME team to just go ahead and fix this bug. I may be wrong, but who knows... Someone needs to ask them. Not me.
Kids, kids, calm down :-) There's no conspiracy. Clearly, we need to work on supporting high resolution displays better. Whether the approach proposed in this bug is the best way forward is not clear.
Seriously though, it's unfortunate that we let this rot. There are three different approaches we can take to implement this: - Both Apple and Chrome seem to implement x2 only. Ie. if DPI is large enough, they scale everything up by a factor of two, but making it possible to render things sharply. We can do this on the cairo level for example. - More like Firefox, CSS. That's close to what the patch here does. Essentially fix 1px to mean "1px at 96dpi" and scale everywhere. Issues with image scaling cannot be solved. Everyone is using SVGs these days, right? - Android has three different classes of dpis, low, med, high... That may work better than the above two. However, since it's unlikely that displays in the 160..200dpi ever show up, just supporting x2 and x3 may be good enough for the next 10 years...
(1) This needs to be fixed first on the X or WM layer, not in GTK. Nobody wants Firefox and Inkscape to look all tiny but control-center all huge. (2) After that, we want to cooperate with those fixes to get the sharpness back. Or we can just wait another 3 years until everything has 500dpi and just have a global "scale up by factor <DOUBLE>", because sharpness of pixels doesn't matter anymore. ;)
(In reply to comment #32) > Or we can just wait another 3 years until everything has 500dpi and just have a > global "scale up by factor <DOUBLE>", because sharpness of pixels doesn't > matter anymore. ;) How does *that* work?!
Extra-sharpness, aka, aliasing, wouldn't matter at 500+ dpi. Lack of sharpness (bulky pixels or even bilinear / trilinear, any upscaling filtering) does matter a whole lot more the higher resolution you have... At that point you want this: http://research.microsoft.com/en-us/um/people/kopf/pixelart/
"However, since it's unlikely that displays in the 160..200dpi ever show up, just supporting x2 and x3 may be good enough for the next 10 years..." (Facepalm) The new MBP is 220 ppi. Ultrabooks at 1920x1080 on 11" and 13" are 200 and 160 ppi approx. And they are for sale NOW, not "maybe in the next 10 years". This kind of "living under a rock" is what I'd like to shake up a little, precisely. "Extra-sharpness, aka, aliasing," (Facepalm2) "Aliasing" is exactly the opposite and is the result of not enough samples when digitizing something. In CG it refers to the staircase effect that becomes apparent when drawing with not enough pixels. High ppi monitors reduce aliasing by adding more pixels to the same drawing. Thus, anti-aliasing techniques are needed when using fewer pixels. But all of this has little to do with the issue at hand. What we need is a way to represent information in GTK with a physical or relative unit, not pixels. "This needs to be fixed first on the X or WM layer, not in GTK." Or just cooperate with those two and make unified and sensible specs, abandoning once and for all the use of pixels as the unit to express the size of primitives to be drawn on a computer screen. I don't think anyone cares where the conversion from a unit to final pixels is taking place, as long as pixels are deprecated as the basic unit for developers. I understand that both Windows and OS X are taking shortcuts to the "real thing". We shouldn't, because GNOME will work on many different hardware setups, which makes it hard to assume anything about it.
(In reply to comment #35) > "However, since it's unlikely that displays in the > 160..200dpi ever show up, just supporting x2 and x3 may be good enough for the > next 10 years..." > > (Facepalm) The new MBP is 220 ppi. Ultrabooks at 1920x1080 on 11" and 13" are > 200 and 160 ppi approx. And they are for sale NOW, not "maybe in the next 10 > years". Last I checked 220 was greater than 200. > This kind of "living under a rock" is what I'd like to shake up a little, > precisely. Reread your first-grade Math and English Comprehension books :-). > "Extra-sharpness, aka, aliasing," > > (Facepalm2) "Aliasing" is exactly the opposite Dude. Believe me. I know what aliasing is. :)
@Behdad Esfahbod: Maybe you can try some English writing books... There ARE, today, 160 to 200 dpi displays out there. It is NOT unlikely "that they ever show up" so "we won't be good enough for the next 10 years" with your solution. "Dude", you don't have a clue of what aliasing is. http://en.wikipedia.org/wiki/Aliasing
Call to order. Cut out the bickering about language, both of you. This is a bug tracker, not a mailing list...
Ok, sorry. Thought everyone's having fun :). Aleve, I said I don't think there will be many displays showing up in the 160 to 200 range. Ie. monitors will either be in the 96..140 which they are right now, or 200+. So we don't have to worry much about, say, scaling things 1.5 times. Just being able to scale 2x, 3x, 4x, etc should be good enough.
(In reply to comment #30) > Clearly, we need to work on supporting high resolution displays better. Whether > the approach proposed in this bug is the best way forward is not clear. FWIW, I'm pretty sure we want something simpler than what I proposed here four years ago. Basically, what Behdad says in comment 31 bullet 2, which indeed is close to my patch minus the unit/encoding stuff. But before even touching GTK+, I'd worry a lot more about designing and implementing the user experience in the control center (a slider ranging from "Smaller" to "Bigger" with 1.0 in the middle as the default) and do the g-s-d stuff so there's an XSetting (set to 1.0 by default).... (I'd also run this by some designers but at the end of the day any design will end up with a scaling factor one way or the other). Then I'd hook the scaling factor in XSettings up as a property on the GtkSettings object in GTK+ (including a notify:: signal) ... and only then, I'd worry about actually making the rest of GTK+ use it. I mean, once you have the above, it's not a lot of work to just experiment with various approaches - writing the original r-i patches didn't take me _that_ long and if I had skipped the whole unit/encoding madness, it would have been a lot less work (and maybe even in mainline, who knows).
(In reply to comment #40) > Then I'd hook the scaling factor in XSettings up as a property on the > GtkSettings object in GTK+ (including a notify:: signal) ... and only then, I'd > worry about actually making the rest of GTK+ use it. > > I mean, once you have the above, it's not a lot of work to just experiment with > various approaches - writing the original r-i patches didn't take me _that_ > long and if I had skipped the whole unit/encoding madness, it would have been a > lot less work (and maybe even in mainline, who knows). Oh it's probably much easier these days. Changes needed are kinda similar to color-space support, so would be good to see what the story there is. I think this should do: - Make X / Xft / Render scale up transparently. This will be for legacy systems. This probably should be per X window. - Make cairo's / Qt's X backends do the same. This would allow sharp text even if the app has no clue we're scaling up. - GTK+ will use the cairo support to scale up all apps by default. Now that we have draw() taking cairo_t, this is much easier than old expose(). Widgets can override something to disable this and do its own.
(In reply to comment #39) > Ok, sorry. Thought everyone's having fun :). > > Aleve, I said I don't think there will be many displays showing up in the 160 > to 200 range. Ie. monitors will either be in the 96..140 which they are right > now, or 200+. So we don't have to worry much about, say, scaling things 1.5 > times. Just being able to scale 2x, 3x, 4x, etc should be good enough. And I said there currently are both 160 and 200 ppi monitors already. What's not to understand? Besides, once high-ppi is the norm (which we can safely expect), we'll see many more gradations, you can bet (more or less the same that's happening in mobile already). Anyways, going for some "on purpose" solution is something OS X can do, not so much Windows, and definitely not Linux, because control of what hardware will run the software is non-existent here. So I'd suggest to focus on the broader -and more elegant- solution possible.
(In reply to comment #40 & #41) I'm not sure how the implementation should work, but I can suggest what the thing should look for application developers and users. App developers should be offered development tools to define measures in non-pixel units (em, mm, inches or others) Users should be offered a simple scale where "1x" or "Normal" (or any other synonym) is "the right size". On that setting an A4 paper with text in it shows the exact size of a real world A4 sheet of paper. Text sizes would have -at last!- the same meaning for any display at the "1/Normal" scale setting. Users wanting more screen real estate -not bothering about WYSIWYG and real world sizes-, can move a slider to the left to 0.5x or other amount, or choose "Smaller". People with special visual needs, or who just prefer big everything, would move the slider to the right to 2x or "Bigger". That's pretty much it. Again, I fully understand the implications of being compatible with software that's already out there. I'm more of a designer than a programmer. I can't comment on the difficulties of the right implementation for that.
Oh, and the ppi settings of a monitor should be deduced from information sent by the monitor itself. A manual override might be available for older monitors in dconf or any other advanced settings tool.
Here's some fun requirements: * Support legacy software If I have a 500ppi monitor I want my XMMS scaled, so that I can actually find the play button. I also absolutely expect xterm to work. * multi-monitor support If I plug my 500ppi laptop into an 800x600 projector, I want my system to show more than just the top left button of the window decoration. * sharp lines If I say my line is "1px" that line looks sharp, no matter if it's on the hi-ppi laptop or on the projector. Also, no cheating like Flash where they snap the line to the pixel grid. That gives jerky animations, I don't want that. * access to the raw pixel grid If I set GIMP to 100% I want it to make 1 pixel in the image correspond to 1 pixel of the monitor, so that I can see the pixels without any effect applied. So the GIMP guys need a way to make that work.
(In reply to comment #42) > So I'd suggest to focus on the broader -and more elegant- solution possible. Thing is, the more elegant solution is actually not elegant. you get blurry lines, text, and graphics all over. That's why Apple waits until they can double the resolution (iPhone: 160dpi->320dpi, iPad: 120dpi->240dpi, MacBook Pro: 110dpi: 220dpi), such that old applications still look as crisp as they used to. (In reply to comment #43) > Users should be offered a simple scale where "1x" or "Normal" (or any other > synonym) is "the right size". On that setting an A4 paper with text in it shows > the exact size of a real world A4 sheet of paper. That totally not work on your screen projector... We want same *angular* density at presumed viewing distances. (In reply to comment #45) > Here's some fun requirements: > > * Support legacy software > If I have a 500ppi monitor I want my XMMS scaled, so that I can actually find > the play button. I also absolutely expect xterm to work. Mode 1. X server does it. > * multi-monitor support > If I plug my 500ppi laptop into an 800x600 projector, I want my system to show > more than just the top left button of the window decoration. Trickier but possible, using mode 1 transparently. Doing it in mode 2 (cairo level) is trickier. Mode 3 is easy, ie. the app knows what it's doing. > * sharp lines > If I say my line is "1px" that line looks sharp, no matter if it's on the > hi-ppi laptop or on the projector. Also, no cheating like Flash where they snap > the line to the pixel grid. That gives jerky animations, I don't want that. Exactly why not supporting fractional scale factors helps. > * access to the raw pixel grid > If I set GIMP to 100% I want it to make 1 pixel in the image correspond to 1 > pixel of the monitor, so that I can see the pixels without any effect applied. > So the GIMP guys need a way to make that work. Mode 3, yes.
(In reply to comment #46) > (In reply to comment #42) > > > So I'd suggest to focus on the broader -and more elegant- solution possible. > > you get blurry lines, text, and graphics all over. That's far from the truth. You just get blurry bitmaps, eventually, and only them. Every vector based graphic object gets perfectly rendered. Of course developers are discouraged from using bitmaps and are strongly advised to use vector graphics. This should go without saying. > That's why Apple waits until they can > double the resolution (iPhone: 160dpi->320dpi, iPad: 120dpi->240dpi, MacBook > Pro: 110dpi: 220dpi), such that old applications still look as crisp as they > used to. This is neither elegant nor suitable for random hardware, which is what we face. On the other hand, making bitmap based apps stand out by looking ugly is a nice push towards vector based graphics all over the place. > > (In reply to comment #43) > > > Users should be offered a simple scale where "1x" or "Normal" (or any other > > synonym) is "the right size". On that setting an A4 paper with text in it shows > > the exact size of a real world A4 sheet of paper. > > That totally not work on your screen projector... We want same *angular* > density at presumed viewing distances. OK. Projectors are excluded from resolution independence unless you manually provide resolution and apparent screen size. Are you just trying to be annoying?
(In reply to comment #45) > * Support legacy software > If I have a 500ppi monitor I want my XMMS scaled, so that I can actually find > the play button. I also absolutely expect xterm to work. You'll get it scaled, but don't expect it to be sharp. Ask your favourite apps devs to go for vector based graphics on their apps. > * multi-monitor support > If I plug my 500ppi laptop into an 800x600 projector, I want my system to show > more than just the top left button of the window decoration. How does your current 1366x768 laptop work? Right, by scaling and cropping. Should be exactly the same. > * sharp lines > If I say my line is "1px" that line looks sharp, no matter if it's on the > hi-ppi laptop or on the projector. Also, no cheating like Flash where they snap > the line to the pixel grid. That gives jerky animations, I don't want that. On a resolution independent system you don't ask for 1px lines. You may use specific libraries for managing pixels, though, which leads me to your next question: > If I set GIMP to 100% I want it to make 1 pixel in the image correspond to 1 > pixel of the monitor, so that I can see the pixels without any effect applied. > So the GIMP guys need a way to make that work. The GIMP -and other bitmap editors- guys should be able to use low level primitives. That's what the pixel should become. They already use their own libraries for working with pixels. I can't see how this might pose a problem.
(In reply to comment #48) > (In reply to comment #45) > > > * Support legacy software > > If I have a 500ppi monitor I want my XMMS scaled, so that I can actually find > > the play button. I also absolutely expect xterm to work. > > You'll get it scaled, but don't expect it to be sharp. Ask your favourite apps > devs to go for vector based graphics on their apps. Only if the app knows about resolution-independence. > > * multi-monitor support > > If I plug my 500ppi laptop into an 800x600 projector, I want my system to show > > more than just the top left button of the window decoration. > > How does your current 1366x768 laptop work? Right, by scaling and cropping. > Should be exactly the same. You missed his point. Not mirroring-mode even. When the screen spans the two displays, someone has to work with two different scale factors, to make the two displays look physically having the same scale.
(In reply to comment #47 by Aleve Sicofante) > Are you just trying to be annoying? Aleve, comment 38 asked you to be careful with the language that you use. Please read https://live.gnome.org/CodeOfConduct . If your comments continue to be disrespectful your Bugzilla account will get disabled. Last warning as I've told you before to be more careful with your wording. Bugzilla is a place to have technical discussions only.
(In reply to comment #50) > (In reply to comment #47 by Aleve Sicofante) > > Are you just trying to be annoying? > > Aleve, comment 38 asked you to be careful with the language that you use. > Please read https://live.gnome.org/CodeOfConduct . > If your comments continue to be disrespectful your Bugzilla account will get > disabled. Last warning as I've told you before to be more careful with your > wording. Bugzilla is a place to have technical discussions only. Comment 38 asked both Mr.Esfahbod and me. You don't seem to appreciate the obvious way out of line comments. Asking him if he's trying to be annoying can't be considered disrespectful by any stretch of the imagination. I call discrimination here.
(In reply to comment #49) > (In reply to comment #48) > > (In reply to comment #45) > > > > > * Support legacy software > > > If I have a 500ppi monitor I want my XMMS scaled, so that I can actually find > > > the play button. I also absolutely expect xterm to work. > > > > You'll get it scaled, but don't expect it to be sharp. Ask your favourite apps > > devs to go for vector based graphics on their apps. > > Only if the app knows about resolution-independence. No. The user can simply set a scaling factor for non-compliant, old apps. All of them will be scaled accordingly. > > > > > * multi-monitor support > > > If I plug my 500ppi laptop into an 800x600 projector, I want my system to show > > > more than just the top left button of the window decoration. > > > > How does your current 1366x768 laptop work? Right, by scaling and cropping. > > Should be exactly the same. > > You missed his point. Not mirroring-mode even. When the screen spans the two > displays, someone has to work with two different scale factors, to make the two > displays look physically having the same scale. Yes, I missed any reference to mirroring mode and the spanning mode. I'm sorry but I still don't get the problem. Both monitors will have their own ppi, communicated to the system automatically or by hand. Graphics will be displayed properly using that info.
(In reply to comment #48) > On a resolution independent system you don't ask for 1px lines. > Which is why all websites specify borders in inches and millimeters and not pixels. In particular Apple's homepage (see http://images.apple.com/global/styles/base.css for example) is using CSS that does not refer to pix... Oh wait! http://www.w3.org/TR/css3-values/#absolute-lengths has the sanest definition and explanation for this stuff to date. It is also very clear that we will always be talking about pixels. Just that a pixel might not be what you think it is anymore...
Quick note on windows spanning over or moving between multiple monitors with different DPI: Mac OS X seems to handle this by bringing the window manager / compositor into the equation. Any given window takes the scaling factor of the monitor it's mostly on, either drawing into a 1x (low-res) or 2x (high-res) backing store. The window compositor then appears to scale the window appropriately for each monitor that it appears on -- this way a high-res application on your 220dpi laptop screen that spills over to a 100dpi external screen looks approximately 'right'-sized on both, or vice-versa. When moving a window from one screen to another, it gets reassigned to the other monitor and its scaling factor may then change. (Sends an event to trigger redraw etc, much like resizing.) Window manager hints about which windows are at which scale might be something that helps with a Gtk/X11-y implementation, but might require some help from the window manager to handle actual sizing of the windows. A non-compositing window manager would presumably just let the windows spill over looking weirdly sized, but still be ok for windows that don't span screens.
> We want same *angular* density at presumed viewing distances. Wow thank you Behdad. As a vision scientist we only ever talk about sizes in degrees of visual angle. All this talk of screen resolution when people mean screen dimensions makes me despair. Also the term »retina display« is a joke when the viewing distance is unspecified. My laptop has a retina display when I stand 2m away from it.
I think a good first step toward solving this problem is to generate a well defined list of requirements for any solution. I've come up with this list based on my understanding: REQUIRED: R1) Support legacy software: Software that is unaware of RI should be scaled. R2) Multi-monitor support: Scaling must be defined and applied separately for each display device. R3) Direct pixel access: As mentioned GIMP, OpenGL, etc. need direct access to the underlying pixels. R4) User-adjustable setting: This scaling needs to be adjustable by the user. HIGH: H1) Default scaling: The system should try to choose an appropriate default scale based on the display device MEDIUM: M1) Sharp lines: When scaled, applications specifying 1px lines or bitmap graphics should remain sharp. (NOTE: This requirement could possibly be split for RI aware/legacy applications) M2) Support arbitrary scales: An ideal fix will allow scaling by any arbitrary factor. LOW: L1) Proper Units: As mentioned, the ideal unit will be a visual angle, since this removes dependency on display density and viewing distance. I'm sure that I've missed some, but I believe this is a good preliminary list. On this list, there are two requirements that are in contention with each other: M1 and M2. Before we can make headway on this issue, we will need to chose to promote either M1 or M2 to high priority. I'm not saying it won't be possible to fulfill both, but we can't expect to decide on an implementation until our list of priorities is resolved.
M3) Physical Units: Applications should be able to able to draw shapes with a certain physical size (e.g. 1:1 zoom of a 2D CAD drawing).
closing this as we have hi-dpi scale support now - it is not quite the same thing, but close enough to render this bug obsolete