I am working on an OpenGL application. I use a high-dpi screen, and the Windows GUI is scaled to 125%, to make the programs look like on a regular screen.
If I create a 800*600 window using SDL2, it appears the same size as in a regular screen, but it is 1000*750 px. Since I use deferred rendering, I have to create buffers with the same size as the drawable area, so I would like to find out the real size of the window in pixels
If I call SDL_GL_GetDrawableSize I incorrectly get 800*600 instead of 1000*750.
I added the flag SDL_WINDOW_ALLOW_HIGHDPI on window creation.
What do I wrong?
Edit:
If I change DPI Awareness in Visual Studio to Per Monitor High DPI Aware then the window is really 800*600, but it looks small. It should be 1000*750 because the scaling factor in the Windows settings is 125%
Your post is from Dec 2017 and your SDL version (2.0.7) comment from Jan 2018. Your bounty is up to date, but without newer information.
The main problem is, SDL2.0.7 didn't support HighDPI correctly on windows. In May 2017, they prepared a bigger patch, but it was merged on Feb. 2018, so after the version of SDL2.0.7. As far as I see it, it was introduced in SDL2.0.8. The primary changes were made in the file src/video/windows/SDL_windowswindow.c. I compared the sources and the changelog. It's definitively upstream, but someone forgot to write it down in the WhatIsNew.txt, which is very annoying.
I strongly suggest upgrade SDL to at least 2.0.8, better 2.0.10.
Btw. the author of the patch is mentioning, you need to use the new hint SDL_HINT_VIDEO_HIGHDPI_ENABLED.
In the worst case, if you have still trouble, you can use GLFW instead of SDL.
EDIT:
The Questioner provided new informations today.
You can query DPI value per Monitor on windows via GetDpiForMonitor and calculate from that the size.
Since you're using OpenGL with deferred shading: Ensure you're setting glViewPort correctly for every render pass.
Related
I'm trying to make VS Code editor to look exactly like Visual Studio. I made sure the font settings are exactly the same, however text still renders differently in VS Code (it seems "lighter").
Is there any way to fix this issue?
In the image below the top text is copied from Visual Studio while the bottom one is copied from VS code.
I know the difference is subtle but is still pretty noticeable.
Font rendering in VSCode has been a reoccurring issue throughout a good portion of the editors life time. Font rendering, especially in portable GUI's, is affected by several different layers, for example:
Your Graphics Card can affect the way font is rendered (you can try adjusting the graphic cards settings manually).
Your Monitor, obviously, affects rendering. In fact your monitor has a huge impact. (Try playing with your Monitor's Settings)
The color settings that are offered by your OS may have an impact (often times the color settings are the same as the graphic card settings though. Which means you can just use your OS's GUI to adjust your cards settings in some cases (Not on Ubuntu though))_
Somethings are out of your control, like:
VSCode, it is written using Electron v6. Not only does Electron impact font rendering, but when VSCode switched it Version 6 a lot of people reported a decrease in the editors font rendering quality.
VSCode also implements Anti-Aliasing tools, but as far as I can tell, they auto configure, so you have no control over this. These tools are likely to be one of the biggest causes to the difference in rendering you see, between VS IDE & VS CODE. There is a tool however that may give you some control over the Visual Studio side of rendering that I share a link to below. And just as an FYI, the Anti-Aliasing that VSCode uses is called Sub-pixel Rendering, which is something that Visual Studio doesn't implement as far as I can tell.
The Area You Have the Most Control in:
There is ONE tool/thing that you have 100% control over, that also greatly affects font-rendering, and that is the font that you decide to use. When choosing a font, you have the choice of equipping an OTF, or a TTF. In my personal experience, OTF's render better 90% of the time. The difference is in how they are created.
TTF fonts are made using quadratic Beziers.
OTF fonts are made using cubic Beziers.
Links above are the same
Fonts use something called font-hinting
Font hinting. Essentially font-hinting is a list of instructions that dynamically changes the way a font is rendered, by using the rasterized grid background as a parameter. adjust the display of an outline font so that it lines up with a rasterized grid. Choosing a quality font equipped with good hinting is critical for non-blurry readable text.
Many people choose font because like the way they look, or the italic version of the font they use is popular. When choosing a font, it is extremely important to choose, not the coolest one, but the one that renders with the highest quality, and is the easiest for you to read.
Well Rendering Fonts:
Not only are their fonts that render well, with ligature support, but the best rendering fonts are always free IMO. Bellow are Fonts that use font hinting and have top notch rendering abilities.
JetBrains Mono (JetBrain's Font & My Personal Favorite)
Cascadia Code (Microsoft's Programming Font from 2019)
Fira Code (Not that old, but not that new either. Is loved by many.)
Fira Mono (No Ligatures, Different Font than Fira Code)
Consolas (A classic)
Menlo (Another Classic)
The top 4 are at the top of the list because they receive updates ever few months. I don't think Menlo & Consolas receive regular updates, but they aren't left forgotten either, the are updated every year or two.
To finish with as solid of an answer as I can provide:
_"Getting VSCode to render like the Visual Studio IDE, is not something that you will probably get, with 100% satisfaction, getting an exact match with all of the different factors is just an extremely and possibly impossible thing to due. You can probably make the way the two pieces of software render, more a like, not in functionality, but in looks. It would probably help a great deal to make sure that everything that affects rendering is up to date, editor, IDE, fonts, tools, ect... From their you can try different versions, and see if maybe an older version of VSCode rendered in a way that is preferable to you. You should also play with your monitors settings. I have found that I can accomplish a great deal just through the buttons under the face of my monitor. Check Visual Studio for any rendering settings it might have, VSCode doesn't have much available, but maybe Visual Studio IDE does (I haven't used the IDE in 5 years so IDK if it does).
On a final note:
Their is one tool that could help you, I haven't used it, because it isn't for VSCode, it's for Visual Studio, but it might give you more control than you have now. The tool is called..."_
Text Sharp (Click Here to see it in the VS Market Place)
Can I change Qt Creator's (latest version: 4.14.0, Windows 10) general GUI font size (or scaling)?
The problem is, my system display scaling is set to 250% and I have two options for high DPI compatibility in Qt Creator, but both have issues:
I can disable Creator's built-in High DPI Scaling and force System (Enhanced) in the Windows compatibility settings:
Or I can enable Creator's built-in scaling and leave the Windows compatibility scaling override turned off (Application scaling):
In the former case, it's actually a size I find very comfortable except the cursors are all too small and Designer gets wonky (plus it's tricky to layout GUI's because apps all run in System (Enhanced) mode from Creator).
In the latter case, the cursors and Designer work, and it's nice to not have heavy anti-aliasing everywhere, except the GUI font is too large for me, and everything feels cramped (especially the top bar, and the left bar reminds me of one of those old school children's telephones with the huge buttons). Plus the general GUI font is different enough in size from my editor font that the whole thing just feels jarring and kind of stresses me out.
So what I think I'd like to do, ideally, is use application scaling like in the latter example, but just shrink the GUI font size to match the former.
I think I ran through all the options thoroughly, and all I can find is settings for the editor window and the console, but not the rest of the GUI.
To be honest, I'm actually not entirely sure why they don't look the same; my expectation was that Qt's built-in High DPI support would take the scale factor into account in the same way that Windows' System (Enhanced) mode does, but I'm sure it's more complicated than that.
The problem is Qt automatically round up your 250% scaling to 300%. For Qt Creator application, you can create a "QT_SCALE_FACTOR_ROUNDING_POLICY" environment variable, and set it to "PassThrough". You can find details in this question: Qt Creator "too big" on 3840x2160 and 150% scaling on Windows 10.
It's also worth noting that Qt also behaves like this coding a GUI program. This can be fixed with:
QGuiApplication::setHighDpiScaleFactorRoundingPolicy(Qt::HighDpiScaleFactorRoundingPolicy::PassThrough);
I need to display a full screen DirectX window from a Qt app.
Although directX isn't supported directly anymore by Qt this should be easy enough - just override QWidget, provide your own paintEvent() and set a WA_PaintOnScreen attribute.
But when the app is full screen DirectX is grabbing all the mouse and keyboard inputs - so the only way out of the app is ctrl-alt-del.
ps. Even if I wrote DirectX keyboard handlers I would still have to find a way of creating the correct Qkeypress event to pass to Qt.
Has anyone done this? Or is there a simple way to tell DirectX not to grab the keyboard?
To my knowledge Direct3D does not get the keyboard. Your problem more likely arises from the fact that Direct3D in full-screen is quite a different beast. Things like GDI (which Qt may well use to do rendering) do not work by default, the run-time hooks lots of bits of information. That info then, presumably, never manages to get to Qt. The options you have are to re-implement Qt to render using Direct3D (Lighthouse project?) or to use a pseudo full screen. This is usually done by creating a window that has a client area the same size as the screen and then positioning it correctly.
The latter would probably be the simplest solution ...
There was an attempt to get a D3DWidget kind of thing in Qt 4.3-4.5 or something like that, but it never was stabilized or approved and later even removed.
Perhaps indeed lighthouse is an option (with a medium sized amount of work, basically links OS/DX stuff to Qt stuff) or you can take a look at the old direct3D code in older Qt branches. I never used it, and it probably isn't intended to use with recent versions of Qt, but it's better than nothing.
I have a windows application that scrapes pixels from the screen for recording (in the form of a video) to a custom screen-sharing format. The problem is that on machines using a software cursor, blitting from the screen with SRCCOPY|CAPTUREBLIT (so that layered windows also show up in the image) causes the cursor to blink, as described in Case of the Disappearing Cursor.
For single screen shots, this is not a problem, but when multiple screen shots are taken in rapid succession, the cursor blinks so fast that it sometimes seems to disappear altogether.
I have looked into using the Windows Media Encoder SDK (as described in a codeproject article, see below) because it doesn't cause the cursor to blink, but there seems to be no way to directly access the frame data. Unfortunately, both real-time encoding and the custom format are both requirements, which makes windows Media Encoder unusable for this purpose.
I have also tried the DirectX way (described in the same article, see below), and it seems to suffer from the same problem.
Has anyone else run into this problem? There must be a way around it - many commercial screen sharing programs have no such problem.
article: www.codeproject.com/KB/dialog/screencap.aspx
you can use Magnification API in windows vista or later.
i cannot find a good idea in windows xp.
What about using a mirror driver?
You are right, a mirror would certainly work. However, at the moment, I am trying to stay away from that approach because of the security and permissions concerns when installing under a user without admin rights. Correct me if I am wrong, but I don't think there is any way to install a driver without such rights. Besides that, it seems that that would be needlessly complex: there should be a simpler / less invasive way to do this. (I should have mentioned this in my original question)
Just copy the screen and the cursor separately and overlay them.
The thought I had to overcome the flicker is to "manually" draw "your own copy of the mouse", then make the BitBlt call, or to call BitBlt with just SRCCOPY then manually capture any visible transparent windows over the top of it. I don't know how the commercial stuff does it (or the windows media encoder apparently does).
ref: http://us.generation-nt.com/xp-bitblt-captureblt-option-help-26970632.html
Up to now I been using the pda emulator in visual studios 2008 (I am using windows mobile 6.1 professional sdk).
So I just dragged and dropped most of my GUI components into the form. In one instance I made a panel then in this panel I dynamically generated labels in it with certain location positions.
I then put it on my Hp PAQ 110 Classic pda and it looked fine and everything. Then I was looking through the emulators one of them was called professional square. So I decided to run it and when it ran my program it looked like crap.
I had missing labels, missing controls and it just looked horrible.
I thought maybe it would like do some resizing for me but it seems to either did a shitty job or it does not do it at all.
So how do you make a GUI that will work well on all mobile phones(or at least the vast majority of them).
Is there like X number of types of mobile phones? Like the emulator emulates a pda and it works on my HP one so I am assuming that all window mobile device pdas have the same screen size.
Then the next question is how do you make the controls position properly from one device to another? I heard of people using XML files that have all the location position, sizes and etc that they call up and I guess essentially generate the GUI dynamically based on the information in XML.
But I could not find any examples how the XML file would look like, how to detect what phone type it is so that I could call up the right node of the file for that phone.
I am not sure if there are any other ways but this seems better then a set of GUI forms for each one.
Also would it be recommended to have most things in a panel so that way even if the stuff is bigger you can at least turn auto scrolling on.
thanks
I spent a good amount of time looking at different solutions for this problem (see my question here as well) and ended up with a pragmatic approach - consistent use of docking. You have to restrict yourself to the least common denominator, i.e. the lowest resolution you want to support, in terms of how much you can fit on the screen. The good news was that grids always use the entire available real estate, and my forms flow correctly on all devices and the screens don't look like they are broken.
This is far from being an easy task. You can follow some guidelines, but the only thing that will actually work is to always test the User Interface in all possible screen resolutions. Emulators are a good way to start, however it will be better to have an actual device. Some things like font sizes and text readability can only be tested in a real device. So, these are my advices:
Try to use docking for positioning your controls.
You need to be able to handle orientation changes correctly. Using docking helps, but again you always need to test in different screen resolutions.
At some point you will find out that it is inevitable to detect the screen size and adapt the User Interface dynamically. I don't agree that you should restrict yourself to only display what can fit in the smallest screen. A professional application should adapt itself to the available screen size and take full advantage of it.
Structure your application so that it is easy to support new screen resolutions. Make the main User Interface code screen size agnostic. Make it get all information about dynamic resizing - positioning from a configuration class. This way you only need to enhance a single item in your code in order to support a new screen resolution.
And of course:
Test in all possible screen resolutions. After even a minor change to the User Interface, retest.
Eventhough the above posts where helpful this video I found solves all my problems and you don't have to develop for the the lowest screen.
http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=86&webcastid=5112