This allow to keep cpu cool on low powered systems. Old value of 100 fps are kept as default.
I found value of 20 fps to keep my RPI at 700MHz at ~80-85% cpu time. With original value of 100 fps it can produce only 35-38 frames at 1000MHz with 100% cpu time. 20 fps looks pretty good and does not cause any visual defects.
100 fps is unusually high for regular x86 HTPC too.
GUI frame rate moved to advanced settings
A word from my holiday. Do not start adding new options please ! There are way too much already.
So minus a gazzilion on whatever is added to advancedsetting
i understand you. they are a lot, agree.
i can ifdef this one? i thing advanced settings is better place.
how about enabling vsync and use 1080p@24 resolution - then the pi will only render with 24fps. That's what I do and it's working really well. So no need for the additional setting or a ifdef. Lowering the default in general to ~60fps would be an option though IMO.
That works for 24fps content, if display supports 24Hz.
But 25/30 fps will generally choose 50/60Hz as 25/30Hz support is rare on TVs.
(and actually the frame rate matching algorithm always picks the highest multiple which means 25/30 never gets chosen).
... INFO: GLES: Enabling VSYNC
... ERROR: GLES: Vertical Blank Syncing unsupported
manually selecting 1080p@24 produces ugly look because actual resolution selected is 1280x720@24.
with forcedswaptime hack and 1080p@24 i get 1280x720@24 under actual 1920x1080@60, so again ugly, but with 100% cpu
this patch limits frame rate for menus only. playback still uses media frame rate and tv switches to frequency as popcornmix described.
I apply this patch for Rpi and dont work. I still have 9 fps in gui.
"ERROR: GLES: Vertical Blank Syncing unsupported" is fixed and was actually a lie. VSync was enabled or there would have been another error message. Since the real problem this solves seems to be elsewhere, look deeper.
GLES error was taken from my xbmc.log with XBMC up to date as per previous comment. may be i didn't used correct option to enable it, i do not know. fact is that i get this error if i enable Vertical syncronisation by GUI.
till now this is only working way to lower GUI frame rate so CPU is not at 100%. all around the world ask for such way. if there is another, their problems will be already solved in this other way, but they aren't.
even if VSync work, as it is intended to match monitor refresh rate with rendering one, and because TV support 60Hz, it is impossible for RPI to produce such rate and it uses 100%. this 'hack' limits XBMC attempts to follow VSync refresh.
this work only for GUI rendering and leave media render as before. i prefer not to touch algorithm described by popcornmix too, as it have effect on media rendering too and will have negative effect at all.
may be you are right and this solves, or even worse, hides, other problem. then this can be used as starting point for investigation.
if setting vsync really fails, then you should see
CLog::Log(LOGERROR, "%s,Could not set egl vsync", FUNCTION);
coming from CWinSystemEGL::SetVSyncImpl
i thing we miss the point here and i am partially guilty for this. my reaction when VSYNC was mentioned here was not adequate. also right now i tested 8d2e0fe and it does not deal with problem here.
this hack is similar to d72df19. hack i use here was present in system from a long time, i just add a way to manipulate it without recompile.
it doesn't deal with GLES or others, so it is not related to VSYNC. i thing VSYNC work is not affected by this, and is not related to this. at least this work in this way on RPI, as it have custom algorithm for media rendering. on other systems this can lead to other limitations, that is why i made it a setting.
this hack actually limit main loop cycles per second, not only GUI frame rate. because dirty regions aren't supported worldwide, on some systems GUI rendering is usual main load of each cycle, that is why by lowering them i lower actual CPU usage. we don't need to render each GUI frame at such high speed. by doing that and allowing CPU to sleep longer, i cheat governor and it keeps CPU at lower speed. i didn't mess with underlying systems, i just limit memory buffer rendering. under this GLES work on its full power. also TV link is at correct 1080p@60, i throw new memory buffer to it at only 20 fps.
that is what i have in mind when i do that. after all, may be i miss relation to VSYNC, it is not intentional.
here i didn't tested music visualization with lowered frame rate. they are pretty aggressive, so may be they will cause high CPU usage even at lowered frame rate. i never seen some music visualization working flawlessly on my RPI and they are disabled by default here.
ok, i managed to achieve even 29% CPU time only with VSYNC. that was on only one place. system info dialog still consume 98+% and governor is at high speed. RSS feeds also causes 98+%. weather window also. need to continue? don't thing.
no one interested by this 'hack'? no one interested by limiting entire system at idle when it actually is idle, without additional reservations what to stop and what to not open/use?
I apply this patch and added framerate 20 to advencedsettings and nothing change on Rpi. Why??.
it depends. regarding your previous post here, you are getting 9fps for some reason. this limiter doesn't allow more frames than you can now, it limit upper side, ie, it will limit to 20 only if you get 35, or 50, or 100 frames per second.
there are another dependency too: it work only for VSYNC_DISABLED or VSYNC_VIDEO due to existing logic in CApplication::Render().
Thanks for explanation. Patch working perfect when i disable vsync.
for me this work on my old low powered laptop too ( windows based ).
starting from today, i would prefer to postpone this and see #2681 ( GUI Renderer abstraction and move to deferred rendering ) finally added. eventually after weighting its results i/we can rething regarding this.
I've got this problem on Ubuntu with XBMC. I can tell the main menu is getting extreme FPS because any time something gets too much FPS, my sound card makes a lot of static noise. I'm not sure why, but it does. I don't get this at all in any other application in Linux, and it really only appeared a lot in Windows. However, I am certain this is the issue I have in Linux with XBMC because it is giving the same symptoms of having too much FPS. During playback of a video, I know that XBMC syncs to the framerate of the video or refresh rate and the static stops. The menu also has extremely high CPU usage, I suppose from trying to feed my GPU until it is full, and this is a Radeon HD 7950 which takes a lot to get full.
every one with low powered machine have this problem, no matter what OS it uses.
even on high end machines menu eats a lot of CPU resources. but, hey, high end machine for just media center???
currently on PI i get around 40-43 fps in menus. in terms of bigger fps, situation is much better compared to pre render refactor, but still not enough to put CPU in idle, so this PR again is still actual ( may be after some adaptation to current code ). let responsible people think again about its idea. thanks.
Well, it's not a high end machine 'just for media center' purposes. My specs are extreme, but this is my desktop. When I want to watch videos, I could always use VLC, but XBMC is more convenient. Example, I feel like watching episodes of anime, my screen is 28 inches so I can just sit back with my keyboard, hit the SUPER key and type xbmc and enter, then navigate XBMC with the keyboard from afar (it's a wireless keyboard). Considering I have over 10,000 episodes and over 100 movies, I've got a lot to keep track of.
4GHz AMD FX-8120 CPU
16GB 1866MHz DDR3 RAM
Radeon HD 7950 3GB GDDR5 GPU
Creative Recon3D Sound Card (yes, it works in Ubuntu)
240GB Seagate SSD
1x 2TB HDDs
1x 3TB external drive
2x 1TB portable drives
My movies and episodes are not stored on my desktop but on the Ubuntu file server next to my desktop. All of the devices I own are symlinked to the server so I can use XBMC and access my archive from any system with ease.
Now, XBMC actually consumes over half of a CPU core, 2GHz of one of my eight cores just to render the menu. Meanwhile, when I play a 720p 10-bit H.264 episode of anime, it only consumes 30%. Does the menu really have to require more CPU than playing a 10-bit H.264 episode of anime, and I see so many people complaining that their Pentium IIIs and Raspberry Pi's can't play 10-bit videos but it's their own fault for using outdated or prototype technology reliant on FPGAs to decode video. With VLC now, it only consumes around 10-20% for the same video. I've got issues with how XBMC decodes video, but that's another problem.
i think you don't understand my idea.
i talk about low powered machines. XBMC plays on some embed systems too, not only on x86.
my dedicated media center is based on AMD E350 and runs 24/7 EDEN. yes, still i use EDEN for my main media center. even it can handle menu redraw and can idle from time to time. i hear that some ATOM and/or ION CPUs doesn't present themselves as good as my E350. real problem is on embed systems or ones without HW acceleration. because of their price, they are perfect candidates for XBMC media centers, but with this unjustifiable resource consumption, they are out of the game. even your system is out of 24/7 game, at least because of power consumption of one of your cores.
What are you talking about? That has nothing to do with how XBMC runs off and tries to render as many frames as possible on the main menu. You were criticizing me for running XBMC on my high end system as if it was odd and inferred that it was 'just a media center'. I replied and now you you want to refute it?
Look, such hardware was NEVER meant to be used as a HTPC, EVER. It's not my fault that you or some other people made the stupid mistake of buying crappy hardware and crying and complaining because you demand FPGA decoding. You shouldn't require FPGA decoding, period. That does not make for a good HTPC system.
Instead, you should have spent $350 on a nice quad core 4Ghz AMD APU system with a 2TB hard drive and 8GB of DDR3 memory, then pay an extra 50-80$ for a nice high end TV tuner so you can record radio and TV directly to the hard drive and also have the capability to transcode with extreme compression parameters to save space while retaining quality. Then, you can buy a nice $100 sound card to get amazing 7.1 surround sound with extreme audio clarity. Don't even try to argue about the cost, because the price of media for a HTPC is far outreaching the price of the system itself.
If you want to complain about power consumption, such inference is moot. You realize that at 4GHz, running one CPU core to 100% on my eight core processor is only 20 watts of power consumption, plus overhead of over peripherpals. If I cared about 'power consumption' I could downclock to 1GHz and have as little as 5 watt power consumption and decode 10-bit H.264 perfectly fine. However, I don't give a crap about power consumption. I run an entire cluster to 100% on all CPU cores in World Community Grid. Complaining about power consumption just means you got fed some BS and you ate it all up without questioning.
sorry mate, i never critique you. use whatever you want.
i try to explain why this PR was born and what is idea behind it. i never mention your system with bad meaning.
believe me, my HTPC is not cheap one. my MAIN HTPC. it has enough power to handle all HTPC tasks plus a lot more. this is out of scope of this PR. here i try to contribute to XBMC community to get its product used on many platforms in better way. i try to give some freedom for less popular platforms to attend XBMC world happily.
guys, can you move this discussion to the forum please? Every comment in PRs is spamming all XBMC devs, so they should be code related.
Nope, as some childish forum moderator banned me after I made one highly informational post about 10-bit H.264 encoding. How it works, what it does best, video and screenshot examples. He permanently banned me with "Banned for giving out advice so bad it makes babies cry" while also banning my IP address and even banned my wiki account which I edited the 10-bit H.264 page which had incorrect information, poor English, and was severely lacking information and references. That ban reason was, "No. Go away troll." XBMC team has more than just code issues if they allow people like that in their team to shoot the entire community in the foot.