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.
Related
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.
I'm running in a bit of OC situation here. I'm developing an application using LWUIT 1.5. So I'm almost done with the application, I've already added transitions in fact. But I noticed that the application is lagging on the phone(My current test phone is a Nokia C3-00). The transitions are starting halfway.
Do you guys have any advise on how do i optimize my application? I know I could use the Next Form properties of the Form, but I wouldn't want to always show a "splash screen" every time the user will go to another screen.
Nokia's are often very slow with translucent images, any image that contains a translucent image would be pretty slow which includes image borders. Another culprit is overly narrowly cut image borders, there is a workaround for this in Codename One though.
Remove the theme and create a blank or theme that only uses colors. See if speed improves.
Assuming it does then slowly remove suspect elements from your theme. If it doesn't then see if you load large images etc.
PyQt experts: I developed the GUI in Windows and used setGeometry to position the widgets. When I tried to run the same code in Linux it looks cluttered.
And added to that in Windows the font size of 8 seems good. But in Linux, especially in Ubuntu, it doesn't appear well since the font size is 10 by default. Some among the differences are the border of the group box doesn't appear in Linux while it is visible in Windows..
Is there a way that I can make the same code to get the same look and feel in Windows and Linux irrespective of the font and size changes and other differences?
In future if I port my application to Mac will the same code work there too? Or should I have to maintain the separate code for each by checking with platform.system() equal to "windows" or "linux"?
The answer is simple: don't use setGeometry directly (to position your widgets).
Consider the following: what if the user wants to resize your application window?
Compose the user interface (you could do this from Designer or from code) within QSplitters (if you want a resize handle between two components) and/or within QVBoxLayouts / QHBoxLayouts (note that these can be nested).
This will make your UI components behave consistently.
I agree with #ChristopheD. Using setGeometry is bad. It's like designing a webpage with fixed pixel geometry and then wondering why it looks bad on another device.
Qt has a lot of wonderful layout code. Let it do it's job.
Qt by default will paint a widget according to instructions contained in the QStyle. You can test how badly you break your layout in different styles easily enough... run your program with different style options. Like so:
program.py -style motif
Also try -style platinum or -style windows. Even different versions of Windows will probably break your layout.
If you really want to see how bad pixel-based layouts are, try running your program with the -reverse parameter... that's how your program will look to someone running it who speaks a Right-To-Left language, like Hebrew or Farsi.
The problem that you have with widgets not drawing where you want them to can be solved by creating custom painting code for your widget. See the PyQt QPainter docs or better yet, the original Qt QPainter docs..
While I hope my answer is useful, it probably means your program needs to be partially rewritten. In the long term, however, it means that you'll have code that is portable between styles and operating systems, and will even work translated (assuming you care about that).
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.