Very slow mode changes/screen updates with RC15 vs RC14 - any cure?
Pages: 1 2
Neil Fazakerley (464) 124 posts |
I’ve just upgraded a number of R-Pi units to RC15 from RC14 and find that running single-tasking Basic programs from the Desktop is ponderously slow. There’s a 1.5 second pause on an empty screen before the program’s output appears. Similarly, if Escape is pressed, there’s 1.5 seconds of blank screen before the Desktop reappears. Nothing else has changed except the OS version. Under RC14, the screen updated almost instantly. How can can I persuade RC15 to update like RC14? Am I missing a setting somewhere? |
Jeffrey Lee (213) 6046 posts |
That will be a side-effect of the GPU mode change support. Previously the OS was only able to control the dimensions + colour depth of the screen, leaving the GPU to scale it to whatever physical mode was selected in config.txt. But with RC15 the OS is able to control the video mode timings directly, resulting in behaviour that’s much more consistent with other RISC OS systems. There are a couple of downsides to this. One is that you won’t be able to use arbitrarily-sized modes; they must be modes which your monitor supports (this will be solved eventually via building some kind of display scaling support into the OS). The other downside is that mode changes will appear to take longer. Generally it will be your monitor which contributes the most to the delay – the computer is able to change mode pretty quickly and will carry on running, but your monitor will take a second or two to lock on to the new signal and start displaying an image. If you want to switch back to the old behaviour, you can create a file |
Neil Fazakerley (464) 124 posts |
Many thanks for your quick response, Jeffrey. I created that file and, as you say, everything’s back to ‘normal’. What’s the downside of using it from the casual user’s point of view – is there any? |
Clive Semmens (2335) 3128 posts |
I can’t speak for all casual users, obviously – but it suits my purposes admirably: I have several very usable modes between 1920×1080 and 3840×2160 on my 4K monitor by using it. The monitor doesn’t offer anything between those two, just those two and some lower resolution ones. Been in use now for several months with no issues, most often at 2880×1620 but sometimes various others up to and including 3840×2160. |
Rick Murray (539) 13400 posts |
I use If you want to play with multiple modes or support insanely big modes (hello Clive!) that might not be listed as options to CONFIG/TXT, then letting RISC OS control the GPU will be the best option. If you would prefer to lock the machine down to the native resolution of your monitor and have the GPU scale everything to fit (including larger modes, it scaled HD1080 to fit), then letting the GPU take care of itself may be better… |
Steffen Huber (91) 1945 posts |
The GPU scaling might be lower quality than your monitor’s scaling. And sometimes, monitors report their non-native resolution via EDID, which confuses the Pi, you have to put your preferred video mode also into config.txt in this case. |
Clive Semmens (2335) 3128 posts |
Utterly insane to want to have four windows into a 1000 line BASIC file, each ~50 lines & 136 columns, and NetSurf, and a couple of filer windows, all visible at the same time. Yes, utterly insane… Or Drawfiles of architectural drawings, without having to scroll around them to see the details. |
Rick Murray (539) 13400 posts |
☺ |
Clive Semmens (2335) 3128 posts |
Ah, now, how do you do that on here? 8~) |
Rick Murray (539) 13400 posts |
Wrap the text in span tags, then inline some CSS. It’s the same way I did my giant blinking magenta “WAH!” way back when. ;-) |
Clive Semmens (2335) 3128 posts |
What text? I C no text! As for CSS – well, I’ve done a bit when I’ve needed to for my website, but strictly only on a need-to-know-and-not-very-much-of-that basis… |
Rick Murray (539) 13400 posts |
The smiley face is a Unicode character.
|
Clive Semmens (2335) 3128 posts |
Ah – thanks – now that’s something I do understand, although I’ve never troubled myself with that class of Unicode characters. I find Unicode’s accented characters (instead of accents preceding the character they belong to, typewriter style) irritating enough, but comprehensible. Emoticons? Well, at least a smiley face is comprehensible, but it’s gone altogether bonkers imnsho… |
Rick Murray (539) 13400 posts |
One might say there are attributes to multi-gender and multiracial emoticons… |
Clive Semmens (2335) 3128 posts |
Multi-cultural perhaps more to the point? I have some insight into South Asian cultures*, but East Asian ones baffle me considerably. I think the smiley face works pretty much anywhere, but most of the others are about as comprehensible as hieroglyphics. Which themselves are of course entirely entitled to a place in Unicode, so I shall disappear in a puff of my own logic forthwith. * Including some Indian ones that most Indians find baffling… |
Jeffrey Lee (213) 6046 posts |
Back to the original topic…
Generally there are two downsides:
On the upside, old-style numbered modes are more likely to work, which is one of the reasons why we’re looking to add some kind of display scaling support to the OS itself (making sure to use hardware scaling where possible) |
Clive Semmens (2335) 3128 posts |
I really don’t know for sure where the scaling’s going on on my system. The monitor is getting everything in its native 3840×2160, at 24 Hz, that I do know – |
Jeffrey Lee (213) 6046 posts |
You’ve got the GPU driving the monitor at its native resolution, and (apart from eigen values) RISC OS doesn’t contain any scaling support, so it’ll be the GPU that’s doing all of the work. |
Clive Semmens (2335) 3128 posts |
Cheers! |
Steffen Huber (91) 1945 posts |
I never tried – does Pi GPU scaling consider the aspect ratio? |
Clive Semmens (2335) 3128 posts |
It’s configurable. I have |
Jeffrey Lee (213) 6046 posts |
I believe it always maintains the pixel aspect ratio between the input and the output. I.e. it’ll use the same scale factors in both the horizontal and vertical direction, letterboxing the image as required. Which is fine for most cases (square-pixel mode on a square-pixel monitor) but wrong for others (e.g. 640×256). Definitely better than mindlessly stretching the image to fill the output, though. |
Clive Semmens (2335) 3128 posts |
I was about to say, “Someone (probably Jeffrey) will correct me if I’m wrong” – and got called away… 8~) Does the disable_overscan do anything? I could try it, but (a) if someone knows, it’ll save me messing with things, and (b) unless it really matters I’d rather not mess with things anyway – it’s all working very nicely! |
Jeffrey Lee (213) 6046 posts |
Yes. In fact, I think my assertion that the GPU uses the same H+V scale factors is only true if overscan is disabled. If overscan is enabled then it messes with the calculations a bit – because the GPU assumes that you’ve got N rows/columns around the edge of the display which aren’t actually visible (and N can be different values for each edge of the screen). E.g. if you have a 1080p screen but 100 rows+columns of overscan on each side, a 1920×1080 mode will be squashed so that it fills the middle 1720×880 pixels of the screen. But the net result (assuming you’ve got overscan configured correctly) should be the same, i.e. a 4:3 mode will be still appear 4:3 on your 16:9 display. |
Clive Semmens (2335) 3128 posts |
Well, it certainly seems to be true in that case, anyway. And as long as you don’t have an old fashioned analogue display, I can’t imagine why you’d want overscan enabled – is it necessary with any modern display? |
Pages: 1 2