Posted 31 May 2020 - 16:26
Hi Ian,
I think, there is problem with VK on slower boxes (hisilicon's ...)
Problem is, that is redrawed all 14 * 5 background rectangles for any cursor movement. Should be better display this background and redraw rectangle, where was cursor only ? Or - fixed big background and remove border lines only ...
See video (Gigablue Trio 4k)
VK.avi 65.71KB
13 downloads
Edited by ims, 31 May 2020 - 17:03.
Posted 31 May 2020 - 16:40
Same behaviour on the Octagon SF8008.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 1 June 2020 - 12:57
Hi Ims and WanWizard,
That screen looks very wrong. I will look at the code but I have never seen the screen paint that way. Could this be a skin issue or does this happen on all skins?
Regards,
Ian.
Posted 1 June 2020 - 13:00
It seems to be specific for boxes with a HiSilicon SoC. I don't see it on any of the Broadcoms I have.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 1 June 2020 - 13:14
Hi WanWizard,
I can't reproduce that effect on any box available to me. The recording is not very high quality but this looks more like a video driver issue as you can't see the cells being drawn it is more like a display scan issue. Is there any way that I can reproduce this issue on a Zgemma H7C?
The only times the whole keyboard grid is redrawn is when the screen is first displayed, when the code returns from the Locale menu, when SHIFT is used or when direct real keyboard input is used. Navigating around the keyboard only draws the current cell.
I can't see how the code could be causing that effect.
Regards,
Ian.
Posted 1 June 2020 - 13:20
Use an PLi image. It works on other images.
And afaik not reproducable on h7.
By the way: The code is not really optimal. If you press right/left self.findStartAndWidth is executed twice. One time for current key and another time for new key.
https://github.com/O...yBoard.py#L1170
For current key everything should be known already, if you just store the result of the last call.
Edited by betacentauri, 1 June 2020 - 13:20.
Posted 1 June 2020 - 13:22
Hi WanWizard,
I just wrote some test code that shows that the entire keyboard grid is *not* being constantly redrawn as per that video. I think the problem lies elsewhere.
Is it possible to test the code against another build of the firmware? I wonder if there has been another change that is triggering the issue.
If I could make this happen on a box available to me I may be able to dig deeper.
Regards,
Ian.
Posted 1 June 2020 - 13:29
I run a Zeus build (uses E2 develop) on my Octagon SF8008. Let me know what I need to test.
Also, I noticed just now on my SAB Alpha that although it doesn't have the "flashing" behaviour, it is slow as f*ck, moving to another key takes about 500ms, so quite a lag is noticable. The SAB uses a Broadcom 7241.
So it might be a generic issue that is just more visible on some than on others...
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 1 June 2020 - 13:30
Hi Betacentauri,
Use an PLi image. It works on other images.
And afaik not reproducable on h7.
This makes it virtually impossible for me to debug. I would really like to see the issue locally so I can analyse it.
By the way: The code is not really optimal. If you press right/left self.findStartAndWidth is executed twice. One time for current key and another time for new key.
https://github.com/O...yBoard.py#L1170
For current key everything should be known already, if you just store the result of the last call.
Are you sure? I need to protect against the user pressing SHIFT, TEXT or other command buttons that may change the grid layout. Remembering a previous layout may result in unexpected results. Perhaps I am not seeing the optimisation correctly or through your eyes. If you would care to give me an sample / example of the optimisation I would be happy to look at improving the code.
Regards,
Ian.
Posted 1 June 2020 - 13:36
Hi WanWizard,
I run a Zeus build (uses E2 develop) on my Octagon SF8008. Let me know what I need to test.
Also, I noticed just now on my SAB Alpha that although it doesn't have the "flashing" behaviour, it is slow as f*ck, moving to another key takes about 500ms, so quite a lag is noticable. The SAB uses a Broadcom 7241.
So it might be a generic issue that is just more visible on some than on others...
This is interesting. One "feature" of the VirtualKeyBoard screen is that it is a complex screen with very many discreet visual elements. There is probably more to paint and render on this screen than any other. That said it is odd any box designed to display a UI efficiently should have so much problem drawing this screen. (Even if it is possibly a worst case sample.)
What version of OpenPLi are you using to see this problem? My Zgemma H7C uses a 7251S Broadcom so perhaps it will be close enough to show the issue.
Regards,
Ian.
Posted 1 June 2020 - 13:37
@ims try change in skin alphatest="blend" to alphatest="on" or remove the parameter alphatest: https://github.com/O.../skin.xml#L1616
Posted 1 June 2020 - 13:41
Hi Taapat,
Thank you for your comment. 
You have reported a very interesting observation. This could be a bug in the driver code and removing the blend avoids the faulty code.
Regards,
Ian.
Posted 1 June 2020 - 13:46
Ian from my point of view start and width of a key is fix. So you can calculate it only once when you open the screen or maybe when you switch shiftLevels. No need to calculate it every time. Or can start/width of a key change?
Posted 1 June 2020 - 13:48
Posted 1 June 2020 - 13:58
Hi Betacentauri,
I am concerned that the UI for the VirtualKeyBoard is totally asynchronous. What if the user mixes input modes while making the data entry. The are things that might change the layout between two adjacent remote control button presses. Such a change may well impact the positioning code.
Please, if you want to suggest a code change give me the code and we can test it out. I am a big fan of optimising code and welcome any suggestions that improve and/or optimise code.
Regards,
Ian.
Posted 1 June 2020 - 14:01
Hi Taapat,
@IanSav maybe it's really a driver bug.
But it is possible that there is some bug in the enigma that does not allow the driver and hardware decoding work as intended.
I rarely use "blend" as I was told that it never worked properly. Even so, I never saw it do anything useful when I tried it so I tend to just avoid it. Perhaps there is something for the device driver people and/or the C++ coders to explore in that warning.
Regards,
Ian.
Edited by IanSav, 1 June 2020 - 14:02.
Posted 1 June 2020 - 14:20
The are things that might change the layout between two adjacent remote control button presses. Such a change may well impact the positioning code.
Posted 1 June 2020 - 14:20
Hi,
I mentioned this issue to some OpenViX associates. I was told that this may be related to a known hardware issue:
That's possibly something to do with the alpha blending issue on the Hisilicon boxes - FORCE_NO_BLENDING_ACCELERATION - its a hardware issue.
You may care to look at how OpenViX gets around the issue or else have a chat to the box manufacturers.
Regards,
Ian.
Posted 1 June 2020 - 14:25
And on my receiver et11000 4K there is this problem.The cursor in the keyboard moves with a delay.To solve this problem I replaced MultiContentEntryPixmapAlphaBlend on the MultiContentEntryPixmapAlphaTest.And the cursor began to move quickly.
Posted 1 June 2020 - 14:27
Hi Betacentauri,
The are things that might change the layout between two adjacent remote control button presses. Such a change may well impact the positioning code.
What things? You are in a screen and I see no way to do something that changes the layout, if it's not already builtin (I don't know the code very well). I only recognized it during some debugging regarding other issue.
If a dynamic layout should be possible, then you need to calculate such things on every key press or build something that calculates it for every changed key.
Please plug a keyboard into your unit and test interchanging between remote control and keyboard input. I don't think I can see the optimisation you are suggesting. Could you please express the suggestion as a code change?
Regards,
Ian.
0 members, 4 guests, 0 anonymous users
