My setup:
Microsoft Surface Pro (version 1), Windows 8.1, Netbeans 8.0, Emacs 24
I noticed that with any given font, in this case Consolas 14, the Netbeans text size is not only smaller, but super crisp on the display. On Emacs, Consolas 14 is huge and kinda blurry. On other programs the text is also not as crisp as on Netbeans. I'm aware there is sub-pixel stuff going on with cleartext, dithering, etc.
So what is Netbeans doing, specifically to look this awesome? Can I get Emacs to look the same? Why is the text different size given the same pt size of 14? How can I get the text to look like this in my programs (assuming on JVM)?
On a regular LCD monitor driven by Surface Pro, the Netbeans text looks a bit less crisp, but the size difference remains, so I attribute this to it being a somewhat lower quality monitor.
I can't necessarily answer your question of "what is Netbeans doing" per se, but I can offer one method for improving the appearance of emacs.
After a bit of research (mostly trial and error, honestly), I found the problem to be related to Windows and its "display scaling." There are many discussions about display scaling on the SP[23] in general, including when connecting to an external display that is not high DPI, Windows is not offering independent scaling factors.
The answer to your question is (I think) loosely related to that. I was adjusting Windows compatibility parameters (right-click on the emacs icon and select Properties then go to the Compatibility tab) for another application when I noticed some options that adjusted color modes (no effect) and DPI scaling (big effect). After some comparisons, I found that checking Disable display scaling on high DPI settings provided a considerably better experience on my screen.
Granted, it isn't "as good" as the same text displayed in, say, Microsoft Word, as really-close-up visual inspection may reveal. Additionally, whenever I put emacs on my non-DPI external monitor, the menus and such as huge, but that's something else to deal with.
In the image below, for comparison is some text in Microsoft Word (top 1) followed by three anti-aliasing options each without (middle 3) and with (bottom 3) the display scaling disabled. The Windows Properties window, Compatibility tab are overlaid for quick reference to what is set. (One interesting side-effect is that the text is roughly 4% smaller now in addition to being much clearer.) Though this example is using the Ubuntu Mono font, it appeared to work equally well with Consolas.
(Windows 8.1, SP3, emacs-24.4.1 from vgoulet.)
This is simply an update on the answer by r2evans. In my version of Windows the Disable display scaling on high DPI settings option no longer exists. Instead, there is an option to Override high DPI scaling behaviour. Setting this to Scaling performed by: System clears up the issue for me.
Related
I was wondering if there's a way to update the default window color when an image is buffering. Currently it's white.
For example, if I have a workspace open with just vscode, when I switch between workspaces there's a brief moment when the screen is white and I'd prefer the monitor be painted black while the image is buffering.
Sometime this issue also happens when moving windows around but it covers a smaller portion of the screen.
Just the color
There is a setting that may be precisely the answer to your question: change the buffer color to black (Check the section in the manual) Particularly, for i3 version 4.21, the config would be this:
client.background #000000
Getting a Composer
If that does not solve the issue, perhaps you could address it from a different perspective. i3wm is a window manager with no "composing" capability. This, among other things, sometimes produces a loss of performance in some graphical tasks, such as problems with smooth scrolling on the browser, and/or flashing colors before showing the rendering of the desktop. (In your case is white.)
So you could obtain a compositor for i3wm. Compton is an option that seems popular among the community. I haven't tried myself, but the lack of compositor may be the root of your problem. Here there is (an interesting related question) in i3wm FAQs. This is part of the answer:
i3 depends on an external application for compositing and Compton is an excellent choice if you want to improve rendering quality or apply hardware-accelerated translucency effects.
There are two issues I am aware of that affect stock compositing. One is screen tearing, which you may notice with animated effects such as Firefox's smooth scrolling. Another is a flash of partially rendered content when switching workspaces, or opening and closing windows. Using Compton should resolve those issues if it is configured correctly.
I'm working on my first winjs app for windows 8.1. So I'm a newbie in this topic, so please forgive me if I ask something obvious.
My problem is the resolution of the target machine (DELL Latitude E7440 with touch screen) is 1920x1080, but when I run the app, it runs in 1370x771. Which is a bit confusing for me.
So my question is, how can I tell the app to run in the same resolution as the OS runs.
Strange thing I discovered: If I set the "Change the size of apps text, and other items on the screen (...)" settings from larger to default in the display settings then suddenly my app runs in the desired full hd resolution. But I don't wanna depend on this setting.
I know I could use ViewBox control, but all of the graphics and everything is designed for full hd resolution, so ViewBox would simply scale it down, this solution sounds a bit ridiculous considering I have a full hd laptop, and full hd design as well...
This app is only for this particular machine, so I don't have to deal with different resolutions.
Any tip/suggestion is highly appreciated.
Windows abstracts the physical device resolution specifically so you don't have to think about scaling issues. Just do your work against the resolution that's reported from the API. This is done because a high pixel density display can result in UI that's too small to be usable, e.g. touch targets that get too small for fingers. Most of the time, then, a 1920x1080 display that's on a smaller physical device (e.g. 13" or smaller screens) gets a 140% scaling factor applied, hence it reports something closer to 1366x768.
Generally speaking, then, if you write responsive CSS for layout then you really don't need to worry about scaling at all with the exception of providing raster graphics that can work at the 100%, 140%, and 180% scaling plateaus (and 240% on Windows Phone 8.1).
For more details refer to my free ebook from Microsoft Press, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition, which you can also read (free) within the Microsoft Press Guided Tour app in the Store. Page 42 (Chapter 1) has a short overview on Views and Resolution Scaling; the Branding Your App section on page 113 talks about sizes of logo/splashscreen images for different resolutions, and then Chapter 8, "Layout and Views" (starting on page 421) goes into all the details, especially "Screen Resolution, Pixel Density, and Scaling" on page 437.
Back in 199[456] I was using Linux and a Matrox graphics adapter. For programming I often used the text mode and didn't bother to boot into X11. These graphics cards allowed for really high text resolutions and still had a very readable font. Occasionally I'd like to test if this font would work well for programming on X11 -- but I cannot find this font to give it a try!
I have searched intensively, for example here, but no font seems to look like the Matrox one. So, the questions:
which font was used? Was it the regular console font that just looked better on those graphic cards?
is this font available for X11? Which one is it?
Any examples / screenshots?
I'd be very glad if anyone could explain if I'm just hallucinating or if my memories are accurate.
UPDATE: I've since found a good resource. Selecting the font Px437_IBM_VGA_8x16.ttf and setting the terminal to 12px comes pretty close to my memories. Since monitor resolutions are much higher now, the font becomes pretty tiny, and scaling it up looks somewhat wrong. I will have to experiment.
This site dumps the ROMs of several old VGA BIOS chips and locates the bitmaps used by the character generator. There's a Matrox card from 1993 in there, but the fonts look quite ordinary to me.
What software or environment were you using, out of curiosity?
Also, have you made any progress on this subject on any other sites? I'm very curious as I'm going to be embarking on a highly relevant project at some point in the future.
I just found this font online -> http://webdraft.hu/fonts/classic-console/
maybe it will help.
I'm currently designing my first ever GUI for Windows. I'm using MFC and Visual Studio 2008. The monitor I have been designing my program on has 1680x1050 native resolution. If I compile and send my program to one of my coworkers to run on their computer (generally a laptop running at 1024x768), my program will not fit on their screen.
I have been trying to read up on how to design an MFC application so that it will run on all resolutions, but I keep finding misleading information. Everywhere I look it seems that DLUs are supposed to resize your application for you, and that the only time you should run into problems is when you have an actual bitmap whose resolution you need to worry about. But if this is the case, why will my program no longer fit on my screen when I set my monitor to a lower resolution? Instead of my program "shrinking" to take up the same amount of screen real estate that it uses at 1680x1050, it gets huge and grainy.
The "obvious" solution here is to set my resolution to 1024x768 and redesign my program to fit on the screen. Except that I've already squished everything on my dialogs as much as possible to try and get my program to fit on screen running at 1024x768. My dialog fonts are set to Microsoft Sans Serif 8 but still appear huge (much larger than 8 points) when running at 1024x768.
I know there HAS to be a way to make my program keep the same scaling... right? Or is this the wrong way to approach the problem? What is the correct/standard way to go about designing an MFC program so that it can run on many resolutions, say 800x600 and up?
I assume your application GUI is dialog based (the main window is a dialog)?
In that case you have a problem, because, as you discovered, MFC has no support for resizing a dialog correctly. Your options are:
Redesign your GUI to use a SDI or MDI GUI.
Use a dialog resize extension. There are many available, for some very good suggestions see this question. Another options are this one and this one.
Don't use MFC. wxWidgets has much better support for dialog resizing.
MFC is only a thin wrapper over the Windows API. They both make an assumption which is hardly ever true: if you have a higher resolution screen, you'll adjust the DPI or font size in Windows to get larger characters. Most of the time, a larger screen size means a larger physical monitor, or a laptop where you want to squeeze as much information into a small screen as possible; people value more information over greater detail. Thus the assumption fails.
If you can't squeeze your entire UI into the smallest size screen you need to support, you'll have to find another way to make it smaller. Without knowing anything about your UI, I might suggest using tabs to group the controls into pages.
I've had good luck making my windows resizable, so that people with larger screens can see more information at once. You need to do this the hard way, responding to the WM_SIZE message to the window and deciding which controls should be made larger and which ones should just move.
There is no automatic way to resize the content of your dialogs when resolution changes. So, you need to set some boundaries.
Option 1.
If you are developing your app for customers, pick one minimum resolution (like 1024x7678), redesign you dialogs so that everything fits. Maybe break up some into several, or use tab strip control.
Option 2.
Create separate dialog forms for each resolution you'd like to support, but use the same class to handle it. At runtime detect resolution and use the appropriate form.
Option 3.
Write your own resizing functionality, so that user could adjust the size of your dialogs to his liking.
Like any responsible developer, I'd like to make sure that the sites I produce are accessible to the widest possible audience, and that includes the significant fraction of the population with some form of colour blindness.
There are many websites which offer to filter a URL you feed it, either by rendering a picture or by filtering all content. However, both approaches seem to fail when rendering even moderately complex layouts, so I'd be interested in finding a client-side approach.
The ideal solution would be a system filter over the whole screen that can be used to test any program. The next best thing would be a browser plugin.
I came across Color Oracle and thought it might help. Here is the short description:
Color Oracle is a colorblindness simulator for Windows, Mac and Linux. It takes the guesswork out of designing for color blindness by showing you in real time what people with common color vision impairments will see.
Color Oracle is great, but another option is KMag, which is part of KDE in Linux. It's ostensibly a screen magnifier, but can simulate protanopia, deuteranopia, tritanopia and achromatopsia.
It differs from Color Oracle by requiring an additional window in which to display the re-coloured image, but an advantage is that one can modify the underlying image at the same time as previewing the simulation.
Here is a screenshot showing the original figure on the left, and the KMag window on the right, simulating protanopia.
Here's a link to a website that simulates various kinds of color blindness:
http://www.vischeck.com/
They let you check URL's and Screenshots with three kinds of different color blindness types (URL checking is a bit dated though. Image-check works better).
I'd encourage everyone to check their applications btw. Seeing your own app with others eyes may be an eye opener (pun intended).
I know this is a quite old question, but I've recently found an interesting solution to transparently simulate color blindness.
When working with Linux, you can simulate color blindness using the Color Filter plugin for Compiz. It comes with profiles for deuteranopia and protonopia und changes the colors of the whole screen in real-time.
It's very nice because it works transparently in all applications (even within Youtube-Videos), but it will only work where Compiz is available, e.g. only under Linux.
Here's an article that has some guidelines for optimizing UI for color blind users:
Particletree ยป Be Kind to the Color Blind
It contains a link to another article with the kind of tools you were asking for:
10 colour contrast checking tools to improve the accessibility of your design | 456 Berea Street
A great paper that explains a conversion that preserves color differences is:
Detail Preserving Reproduction of color images for Monochromats and Dichromats.(PDF)
I haven't implemented the filter, but I plan to when I have some more free time.
I found Colour Simulations easy to use on Windows 10. This software can apply a color-blind filter to a part of the screen or the whole screen. And what's great is it allows me to interact with my PC normally as if it doesn't exist in fullscreen mode. It runs quite slow in my 4K screen using an integrated graphics card, though.