Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[GLES] Check for UNPACK_ROW_LENGTH support on renderer instantiation #15684
Check for UNPACK_ROW_LENGTH support on renderer instantiation not on every LoadPlane call. Additionally check for
How Has This Been Tested?
LibreELEC running on Amlogic S905 and S912.
Screenshots (if appropriate):
Types of change
Apr 6, 2019
1 check passed
As this is SW rendered, we can easily "see":
Please install the nightly before this version, enable debug logging via the GUI. Now play your video and make a recording from the debug display.
And a second one with the nightly at hand, each for one minute pleasse without touching keyboard / control.
Yes, I remember when I forgot to reset it to 0 the GUI overlays were destroyed. Question is what happens if someone uses this in the future for GUI (for reasons we don't know now). This was the reason I saved / restored the value, Does not cost much but could save lot of issue tracking time in the future. GL implementation is not OK for me, too, because it is risky.
But yes, this will not be the reason for the slowness, it will be most likely that he has movies with matching stride where we haven't called glPixelStoreI before, but after thie PR we do.
I just made a strange discovery during the recording:
With debug mode and overlay active -> the video runs super smooth:
Normal playback without the debug mode -> the video jerks slightly as already described:
What could be the reason for that?
To all Kodi Devs: I don't understand how to start with a new Kodi milestone (v19) and still have so many bugs left in v18? When I look at all the playback problems, but also all the hundreds of open issues in the tracker!
I don't think that's a good strategy to leave all the users out in the rain and let them wait for a new stable version in maybe 2 years.
I'm very disappointed by Kodi, which got better and better over the years. Unfortunately this is no longer the case with v18 and now this chapter is simply ticked off.
@kszaq thanks for your feedback, I know that of course.
But it's already being heavily developed on v19 and v18 gets only very rudimentary support, although there are still a lot of bugs included, all of which will reappear on v19.
-> 322 issues still open!
So I would have tried to get the v18 as stable as possible first and then start with the v19 later. What use is v19 to anyone who has a problem right now?
So please stay with v18 for now and make it as stable as v16 and v17 were.
Support? Are we a company selling a product? No.
Cannot repeat this often enough. We are a (small) group of volunteers, doing 100% of this project in our free time. So, we do what we want to do, not, what "customers" want us to do.
If you like what we do / have done you are welcome to use what we "offer" to the world for free. If it doesn't fit your needs, you can look for alternatives.
@ksooo That's all clear, but doesn't change the fact that you're starting to develop a new version and the "old" one isn't even finished yet ;-)
Don't get me wrong, I love Kodi for years and you do a great job in your spare time! That's undisputed. There are also very few alternatives that are at your level.
But v17 was just much more stable and error-free than the current v18, so I think it's the wrong way to ignore that and start other new features. For me, you lost track of your fanbase.
I have already started to go back to v17 and it's not just me. Many of my friends still don't think the v18 is mature. Is that your claim that your fans have to use an older version again?
If you think I'm just an isolated case, why don't you make a simple poll in your forum about how the quality of v18 is rated? If you're not interested in all this, well, I'd just like to give you a thought essay with my post. Nothing more.
There is no such thing like finished software.