2009-09-23, 18:45
I like this change, getting tons of resolution/refresh rates combinations in GUI which never get used is pointless. If there will be an option to have custom resolution list in xml then it's all just fine 
2009-09-23, 23:57
Another possible use for multiple resolutions.
Unless the autoswitch function for refresh is implemented like I asked here http://www.xbmc.org/trac/ticket/6914 (switching before starting the playback), it might be desirable to start XBMC at 24Hz, or 50Hz for PAL stuff, so as to avoid the very slow switch of certain TVs (like my Pioneer Kuro).
And in case one watches a majority of 24fps stuff, leaving the desktop at 24Hz is kind of a pain. The way it was, you could at least leave the desktop at 60Hz and set XBMC at 24Hz.
Unless the autoswitch function for refresh is implemented like I asked here http://www.xbmc.org/trac/ticket/6914 (switching before starting the playback), it might be desirable to start XBMC at 24Hz, or 50Hz for PAL stuff, so as to avoid the very slow switch of certain TVs (like my Pioneer Kuro).
And in case one watches a majority of 24fps stuff, leaving the desktop at 24Hz is kind of a pain. The way it was, you could at least leave the desktop at 60Hz and set XBMC at 24Hz.
2009-09-24, 17:43
ashlar Wrote:jmarshall, a doubt. Here http://trac.xbmc.org/changeset/23019 Elupus mentions a fix for autorefresh, that wasn't working. I supposed that, after a fix, autorefresh would work. But that is not the case, as mentioned.
Is it a problem of my machine? Or are there still missing "pieces"?
I really miss auto adjust refresh rate aswell. I'm on 23120 and it is not switching. Everything else seems to work fine.
2009-09-30, 18:38
Has anything been done on this, so far? I looked on TRAC but couldn't find anything relevant. But maybe I missed something.
2009-09-30, 19:21
Auto refreshrate on windows is still broken since the directx branch merge.. that commit was just for linux.
We have no resolution switching code on windows as it stands for either DX or GL. This is a bug obviousy that needs to be fixed. But windows devs are abit short in supply.
We have no resolution switching code on windows as it stands for either DX or GL. This is a bug obviousy that needs to be fixed. But windows devs are abit short in supply.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
2009-09-30, 21:41
Is there any way a non-coder could understand how and why that bit of code got broken in the gl version? It was working fine before the merge. Obviously this doesn't apply to DX. Just trying to understand.
2009-10-02, 01:36
If there was such a short supply of Windows developers, anyway, I humbly disagree with the decision to touch a portion of code that was working perfectly before. Why fix it if it's not broken?
I just don't get it... sorry. And sorry for not understanding the reasoning behind this. I tried but failed.
I just don't get it... sorry. And sorry for not understanding the reasoning behind this. I tried but failed.
2009-10-02, 01:47
ashlar Wrote:If there was such a short supply of Windows developers, anyway, I humbly disagree with the decision to touch a portion of code that was working perfectly before. Why fix it if it's not broken?
I just don't get it... sorry. And sorry for not understanding the reasoning behind this. I tried but failed.
It's called forward progress, sometime things get broken in the move forward. The directx merge did more than merge dx support, it also re-factored some very, very messy code that was filled with #ifdefs making it very hard to maintain.
2009-10-02, 09:03
Ok, well... I mentioned humble disagreement. Nothing more. I know it's progress and, quite likely, it's gonna be worth it in the long run. For now it's, for me, quite a mess.
Probably I had wrong expectations... for something like a week of unstable versions and then back to the good old upgrading fun.
But, by all means, you are right. Let's move forward.
Cheers and thanks for your answer.
I'll (try to) be patient.
Probably I had wrong expectations... for something like a week of unstable versions and then back to the good old upgrading fun.
But, by all means, you are right. Let's move forward.
Cheers and thanks for your answer.
I'll (try to) be patient.
2009-10-12, 22:18
Is any of the Windows developers working on this? Is it already on TRAC somewhere? Should I add it? Two tickets for resolutions and refresh rate switching? A single ticket?
2009-10-13, 03:50
If it makes you feel better, no really interesting eye candy has been added since the DX break. The experience with 22516 (the last semi-official usable rev) is visually, practically identical to the current experience.
Not very many months ago I had assumed a shift to dx was either impossible or very impractical, so when the decision was made, I was expecting a minimum of a month to even have a usable version. As is, wiso, elisory, and whoever else have really impressed me with the speed.
And if this ultimately results something like a working dxva, then so much the better.
Not very many months ago I had assumed a shift to dx was either impossible or very impractical, so when the decision was made, I was expecting a minimum of a month to even have a usable version. As is, wiso, elisory, and whoever else have really impressed me with the speed.
And if this ultimately results something like a working dxva, then so much the better.
2009-10-13, 10:49
Thanks to the flowers but due to job related issue I had not much time to do much. We're now concentrating on major bug fixing and I'm happy that the other devs have also an eye on the Windows version. Sooner or later we'll concentrate on the DX version and someday the GL version may be discontinued or not further maintained (never say never though 
Ashlar, afaik currently no one is working on the refresh thingy as I think it was the domain of bobo1on1 but I could be wrong as I wasn't that often in the dev channel.
Ashlar, afaik currently no one is working on the refresh thingy as I think it was the domain of bobo1on1 but I could be wrong as I wasn't that often in the dev channel.
2009-10-13, 17:15
Thanks natethomas and Wiso.
Natethomas, I got that impression as well (that is, I'm not losing much by staying with 29130 for the time being). Mine was a genuine question related to the usefulness (or not) of adding a bug on TRAC. Sometimes stuff on TRAC is not that easy to find and I didn't want to add a duplicate bug.
Natethomas, I got that impression as well (that is, I'm not losing much by staying with 29130 for the time being). Mine was a genuine question related to the usefulness (or not) of adding a bug on TRAC. Sometimes stuff on TRAC is not that easy to find and I didn't want to add a duplicate bug.
