Re: [RFC] Linux HiDPI support: choose default scale factor based on DPI
On Thu, Oct 9, 2014 at 10:31 PM, giuseppe.bilo...@gmail.com wrote: I recently got a HiDPI monitor (15 at 3200x1800, 234 dpi) and I noticed that Firefox (32) doesn't automatically scale UI/content to take advantage of the hidpi, with the result that stuff renders uncomfortably small by default. If I manually set devPixelsPerPx to 2, I seem to get a reasonable UI and content scaling. I've perused the source code and did a little bit of debugging, and while the DPI is detected correctly (nsWindow::GetDPI returns 234), no scaling factor is set from this. I've tracked this to the fact that nsWindow in Linux does not reimplement GetDefaultScaleInternal(). Since the patch to implement this is rather trivial, I'm attaching a preliminary version to this post. Still, I was wondering: was the omission intentional (e.g. because other means should be used on Linux for this, and I just happen to have a set-up where this is not detected)? We should really follow what GTK does. E.g. whatever scale factor GTK uses for system/application icons by default, we should match it. Icons in the Firefox UI should use the same scaling as icons in native/system apps. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Linux HiDPI support: choose default scale factor based on DPI
On Thu, Oct 09, 2014 at 11:18:28PM -0700, Robert O'Callahan wrote: On Thu, Oct 9, 2014 at 10:31 PM, giuseppe.bilo...@gmail.com wrote: I recently got a HiDPI monitor (15 at 3200x1800, 234 dpi) and I noticed that Firefox (32) doesn't automatically scale UI/content to take advantage of the hidpi, with the result that stuff renders uncomfortably small by default. If I manually set devPixelsPerPx to 2, I seem to get a reasonable UI and content scaling. I've perused the source code and did a little bit of debugging, and while the DPI is detected correctly (nsWindow::GetDPI returns 234), no scaling factor is set from this. I've tracked this to the fact that nsWindow in Linux does not reimplement GetDefaultScaleInternal(). Since the patch to implement this is rather trivial, I'm attaching a preliminary version to this post. Still, I was wondering: was the omission intentional (e.g. because other means should be used on Linux for this, and I just happen to have a set-up where this is not detected)? We should really follow what GTK does. E.g. whatever scale factor GTK uses for system/application icons by default, we should match it. Icons in the Firefox UI should use the same scaling as icons in native/system apps. But GTK+2 doesn't have support for HiDPI does it? Only recent GTK+3 has, and that's covered by bug 975919 (but, obviously, that's limited to GTK+3 builds, which are far from being production ready). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: `//# sourceURL=display-url.js` in Error.prototype.stack
This would be very useful. I suspect that we can use it to speed up and
decrease the memory usage of the worker module loader.
Cheers,
David
On 10/10/14 00:36, Fitzgerald, Nick wrote:
# Summary
By appending //# sourceURL=foo.js to script text that is being passed
to `eval`, `new Function`, or as the text content of a dynamically
appended script tag, a JS developer can give a name to a script that
would otherwise be anonymous. This is used by many JS module loaders.
Here's an example:
eval(window.foo = function () { return Error().stack; }; //#
sourceURL=my-url.js);
window.foo();
The youngest frame in the stack returned by the call to `window.foo`
would have my-url.js reported as the filename.
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Linux HiDPI support: choose default scale factor based on DPI
In the mean time we should really detect hidpi screens and default to an appropriate scale. The current scale is a terrible experience on a hidpi screen. I filed bug 1081142. Cheers, Nical On Fri, Oct 10, 2014 at 8:39 AM, Mike Hommey m...@glandium.org wrote: On Thu, Oct 09, 2014 at 11:18:28PM -0700, Robert O'Callahan wrote: On Thu, Oct 9, 2014 at 10:31 PM, giuseppe.bilo...@gmail.com wrote: I recently got a HiDPI monitor (15 at 3200x1800, 234 dpi) and I noticed that Firefox (32) doesn't automatically scale UI/content to take advantage of the hidpi, with the result that stuff renders uncomfortably small by default. If I manually set devPixelsPerPx to 2, I seem to get a reasonable UI and content scaling. I've perused the source code and did a little bit of debugging, and while the DPI is detected correctly (nsWindow::GetDPI returns 234), no scaling factor is set from this. I've tracked this to the fact that nsWindow in Linux does not reimplement GetDefaultScaleInternal(). Since the patch to implement this is rather trivial, I'm attaching a preliminary version to this post. Still, I was wondering: was the omission intentional (e.g. because other means should be used on Linux for this, and I just happen to have a set-up where this is not detected)? We should really follow what GTK does. E.g. whatever scale factor GTK uses for system/application icons by default, we should match it. Icons in the Firefox UI should use the same scaling as icons in native/system apps. But GTK+2 doesn't have support for HiDPI does it? Only recent GTK+3 has, and that's covered by bug 975919 (but, obviously, that's limited to GTK+3 builds, which are far from being production ready). Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] Linux HiDPI support: choose default scale factor based on DPI
On Fri, Oct 10, 2014 at 8:39 AM, Mike Hommey m...@glandium.org wrote: On Thu, Oct 09, 2014 at 11:18:28PM -0700, Robert O'Callahan wrote: We should really follow what GTK does. E.g. whatever scale factor GTK uses for system/application icons by default, we should match it. Icons in the Firefox UI should use the same scaling as icons in native/system apps. But GTK+2 doesn't have support for HiDPI does it? Only recent GTK+3 has, and that's covered by bug 975919 (but, obviously, that's limited to GTK+3 builds, which are far from being production ready). I think it should also be considered that the current (and future) builds might be used outside of a GTK-based DE/WM, and some hints at what the DE is using might be missing: in such cases, sane defaults should still be picked. For example, IIRC on GNOME etc DPI usage is enforced by setting Xft.dpi, but I don't have the resource set (I use a plain Awesome WM). Or someone might be running Firefox under KDE, where Xft.dpi is not set because Qt apps generally just use a scaling based on whatever the actual DPI is. Defaulting to a physical-to-CSS dpi scale sounds like a reasonable default. -- Giuseppe Oblomov Bilotta ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documenting uses of Github at Mozilla
One thing to bear in mind re: moving things into the main Mozilla org is that orgs have a maximum number of private repos, and we're bumping up against that limit. If you want a private repo, consider putting it elsewhere. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
