This has been asked for 2015 but the answer seems 2015-specific.
I've turned off Tools->Options->Text Editor->General->Selection Margin and Indicator Margin but still have a 5-6 character wide white area on the left.
It wastes scant screen space, and it makes it impossible to eyeball where the start of a line is when selecting text for copy or deletion.
What other things must one turn off to turn this off?
Related
Using wxWidgets wxStyledTextCtrl I cannot find a way of having the color behind the text to be anything but white. I can change the editor's background but typing in text results in black text with a white background behind the characters.
Searches and review of Scintilla's and wxWidgets docs has revealed nothing to me yet. Any suggestions? (C++, Linux Mint)
update #1: After poking around in the wxWidget source, as a test, I modified in PlatWX.cpp the SurfaceImpl::DrawTextTransparent. I added a call to set brush colour and changed hdc->SetBackgroundMode( wxBRUSHSTYLE_TRANSPARENT ) to wxBRUSHSTYLE_SOLID.
These seems to work reasonably well. However, there are added problems with whitespace. The first being the settings for white space coloring seem to be ignored. The second is a carriage return always leaves a white blank space and multiple spaces having a growing white bow (as on a ship) when holding the spacebar down.
I'm trying to move over to Visual Studio from Eclipse, and I want to bring a similar color scheme with me. But when I change the colors in the options, nothing seems to be changing. This is more than just an aesthetic thing, the different colors make reading the code quickly much easier. It doesn't seem like the colors can be changed, other than basic stuff like line numbers and comments.
Is there anyway inside VS2017 to
a) mark a piece of code with a solid background color ie to know where block starts and where it ends without loosing its color focus when the cursor moves ?
b) to select a piece of code with a solid background color for edge to edge without white spaces inside that ? Current selection leaves whites inside statements and does not color for the 1st column 'till the last one. See below. I installed Visual Assist but it does not seem to do the job.
Seems like it depends on the setting for "Virtual space".
Without it you only have the program code and the cursor never moves beyond the line end. With virtual space the entire window is active and will also be marked edge to edge when selecting lines.
Never mind, this question is a duplicate. I might be able to figure this out from other sources.
I'm so so confused. I was working on my project and realised that the window created with CreateWindowEx() was bigger than I was specifying. I noticed the windows are bigger in release mode than in debug mode. Then I took the values of GetSystemMetrics(SM_CXSCREEN) and SM_CXFULLSCREEN and noticed that in debug mode it gives me 1920 x 1080, which is correct, but in release mode it gives me 1536 x 864.
Furthermore, if I just start a new Win32 project, which is up and ready to run just by pushing ctrl + F5, I get the wrong value in both debug AND release mode, same values as before, and the windows are bigger.
I don't see how providing any code might help, I could make a video of it, but... this just doesn't make sense. Could anyone maybe see if it happens to them by starting a new Win32 project, and seeing 1600 x 900 actually takes up that much space? Because 1600 x 900 takes up my entire screen when it shouldn't.
Thanks.
On further inspection, the 1536 x 864 resolution it gives me is 80% the size that it should be, or in other words it should be 1.25 times bigger, the reciprocal. Also if I change my desktop resolution to 1600 x 900 the metrics gives me 1280 x 720, which is again 80%, or the resolution is 1.25 bigger than what's given.
Well, this is a duplicate, but if this helps anyone I'll explain the problem of DPI scaling. Basically the default Windows setting is 96 DPI. There are options in Control Panel to "make stuff bigger", which is easier on the eyes. My slider is set to the middle one, which is equivalent to 125% bigger, or 120 dpi, which is why System Metrics was returning the wrong values, and my windows were bigger. The dpi gets bigger, so the system assumes it has to draw everything larger in proportion to the upscaling. If you consider someone programs a window to be 200 pixels across, when someone with a super duper double resolution display runs it, it's still going to be 200 pixels across, but half the physical size, say inch-wise. So by doubling the dpi "setting", not the dpi, but dpi "setting" from 96 to 194, or scaling it up 200% makes the window occupy 400 pixels across, but is the same size with respect to the original display.
Anyway, the easiest fix for this, if on Visual Studio, is simply through the project properties, go down to the "manifest" menu, then select "input/output", the last option should be DPI Awareness. Mine was on "None". It's only necessary in most cases to put it on "High DPI Aware", and that will fix the problem. The other option, which is "per monitor DPI awareness" means that it will adjust accordingly in a dynamic way, say for example the dpi scaling is changed while the app is running, or moving the window onto another monitor while it's running. The High DPI Aware setting will do a check at startup.
Interestingly, if you go to the properties of any exe, and under the compatibility tab, you can check "Disable display scaling on high DPI settings", and that will work also. Finally, there is a free program, now owned by Microsoft, called process explorer, which is basically like task manager with extra features, and you can select the DPI Awareness column and see which programs are DPI aware. Yes, DPI Awareness is a thing, I feel so dumb. There are also many other ways to do it, like with function calls and merging manifests, but I have no idea about that, and am too tired to even breathe now.
I noticed in an MFC application I'm developing that while dragging the scroll bar to smoothly scroll down the document, the framerate drops to choppy levels when a block containing about a paragraph of text is on screen, but silky smooth when it's offscreen. Investigating the performance, I found the single CDC::DrawText call for the paragraph of text responsible. This is in an optimised release build.
I used QueryPerformanceCounter to get a high-resolution measurement of just the DrawText call, like this:
QueryPerformanceCounter(...);
pDC->DrawText(some_cstring, some_crect, DT_WORDBREAK);
QueryPerformanceCounter(...);
The text is unicode, lorem-ipsum style filler, 865 characters long and wraps over 7-and-a-bit lines given the rectangle and font (Segoe UI, lfHeight = -12, a standard body text size). From my measurements, that call alone takes on average 7.5 ms, with the odd peak at 21ms. (Note to keep up with a 60Hz monitor you get about 16ms to render each update.)
I tried making some changes to improve the performance:
Removing the DT_WORDBREAK improves performance to about 1ms (about 7 times faster), but given only one line of text is making it to the screen, and there were just over 7 lines with word breaking, this seems to suggest to me the bottleneck is elsewhere.
I was drawing text in transparent mode (SetBkMode(TRANSPARENT)). So I tried opaque mode with a solid background fill. No improvement.
I thought ClearType rendering might be to blame. I changed the font lfQuality from CLEARTYPE_QUALITY to NONANTIALIASED_QUALITY. It looked like crap with sharp edges and all, and no improvement.
As per a comment suggestion, I was using a CMemDC, but I got rid of it and did direct drawing. It flickered like mad, and no improvement.
This is running on a Windows 7 64-bit laptop with an Intel Core 2 Duo P8400 # 2.26 GHz and 4 GB RAM - I don't think it counts as a slow system.
I'm calling DrawText() every time it draws and this obviously hammers the performance with such a slow function, especially if several of those text-blocks are visible at once. It's enough to make the experience feel sluggish. However, Firefox can render a page like this one in ClearType with much more text, and seems to cope just fine. What am I doing wrong? How can I get around the poor performance of an actual DrawText call?
Drawing the text at every refresh is wasteful. Use double buffering, that is, draw in an offscreen bitmap and just blit it to the screen. Then, for scrolling, just copy most of the bitmap up or down or sideways as necessary, then draw only the invalidated area (before blitting the result to the screen).
If even that turns out to be too slow, keep also the drawn text in an off-screen bitmap, and blit instead of draw.
Cheers & hth.,
According to this german blogpost, the issue has to do with support for asian language fonts. If you enable those in XP you get the same perf hit. In Vista/7, they are default enabled and you can't turn them off.
EDIT: Just maybe, using a different font might help.. (one that does not contain asian characters).
Users can't read text at 7 lines in 7 milliseconds, so the call itself is fast enough.
The 60 Hz refresh rate of the monitor is entirely irrelevant. You don't need to re-render the same text for every frame. The videocard will happily send the same pixels to the screen again.
So, I thibk you have another problem. Are you perhaps wondering about scrolling text? Please ask about the problem you really have, instead of assuming DrawText is the culprit.
In order to break the text on word breaks, DrawText needs to repeatedly try to get the width of a block of text to see if it will fit, then take the remainder and do it over. It will need to do this at every call. If your text is unchanging, this is an unnecessary overhead. As a workaround, you could measure the text yourself and insert temporary line breaks and remove the DT_WORDBREAK flag.
Have you considered Direct2D/DirectWrite?
Anyway it should work better if you just draw the text once to its own mem dc and blit that over to whatever dc you want it painted on with each iteration.