OverlayHD - EPG text colours not white

[stevebow]

Using the OverlayHD skin 1.70, the text colour for the EPG event titles and Channel names should be white, but for some reason they are displaying as a light peach/orange colour:

EPG.png (290.43 KiB) Viewed 3623 times

The event description text and "i" icons are white, so it's not just my eyes!

When zoomed, much of the mis-colouring appears to be caused by the text anti-aliasing (if you could call it that...), but even the "white" part of the E next to the Replace Color box is 0xFEF8EE, a warm off-white colour:

EPG_Zoomed.png (78.91 KiB) Viewed 3623 times

The text in both the default easy-skin-aus-hd and Full-Metal-Wizrd skins are rendered as white, so I am tending to think it's a OverlayHD problem. Or is there some setting I have missed? Have tried various settings to no avail.

I suppose I could get used to the colour, but the relevant settings (EPG grid foreground colour, EPG grid service foreground colour) are both white, so white I guess they should be.

[stevebow]

Oddy enough, while playing around with event title fonts, the 9Gem service text colour is suddenly now a cool white (0xEDF5FC):

EPG-9gem.png (305.37 KiB) Viewed 3616 times

Errmmm

[Paul_oz53]

I use the text version of the EPG and it is white. When I swap to "graphics" I see a similar bleed-through effect but nowhere near as bad as yours.

Press MENU in the EPG to change.

[stevebow]

Yes, you're right. In text mode, the text is white, in graphics, non-white. The million dollar question is, why only with OverlayHD and not the 2 default skins.

[MrQuade]

Yes, you're right. In text mode, the text is white, in graphics, non-white. The million dollar question is, why only with OverlayHD and not the 2 default skins.

The text is white in the middle of the stroked from the look of it, but it looks like there is some sort of font antialiasing at work that is causing the edges of the text to render as non-white.

I wouldn't know if there is a specific setting to enable or disable antialiasing in OverlayHD, or if that is hardcoded, or indeed if it is an inherent part of the font that is being used.

Antialiasing is a bit of overkill considering that the UI doesn't scale to the screen's native resolution anyway.

[IanSav]

Hi All,

OverlayHD colour control is biased towards the Text mode of the EPG. I will investigate if I can do something to improve the Graphics mode. I think MrQuade's observation is correct.

Hopefully the Beyonwiz code will be updated soon to allow the current versions of OverlayHD to be used on the Beyonwiz firmware again so that you can get any improvements that I am able to make.

Regards,
Ian.

[prl]

OverlayHD colour control is biased towards the Text mode of the EPG. I will investigate if I can do something to improve the Graphics mode. I think MrQuade's observation is correct.

The thing that puzzles me is why it only seems to affect OverlayHD. An alternative explanation to anti-aliasing is that it is a text border (but I can't see any evidence in the code that one is used). I can't think why aliasing would generate a colour that contrasts so strongly with both the text and the background.

Is the issue specific to Beyonwiz models or firmware versions?

[stevebow]

The text is white in the middle of the stroked from the look of it, but it looks like there is some sort of font antialiasing at work that is causing the edges of the text to render as non-white.

Yep, pretty much as I saw it too.

Hopefully the Beyonwiz code will be updated soon to allow the current versions of OverlayHD to be used on the Beyonwiz firmware again so that you can get any improvements that I am able to make.

Would it be possible to put any updates up on your feed meanwhile? The 19.3 public release could be some way off yet.

[MrQuade]

Would it be possible to put any updates up on your feed meanwhile? The 19.3 public release could be some way off yet.

It goes a bit deeper than that. IanSav's current skin version relies on new features that are available in the major overseas enigma2 distributions, and those features aren't available in any of the Beyonwiz firmware versions yet.

Practically speaking I don't think any major upstream merges can happen in the 19.3 series since 19.3 was focused on making something work for the V2 that could be kept in sync with the T and U series firmware.

Perhaps the next major update will be a big merge update and we get to see a whole slew of new features like we did last time there was a big merge.

(it's a lot of effort for PeterU to consolidate all the custom Beyonwiz stuff with the work being done in the overseas markets since there are lots of features that Aussies want that noone in Europe would want or need, so the code is quite different in places, and it is time consuming and somewhat risky to patch it all together, so it does require a good deal of PVR-crashing beta testing too )

IanSav has long campaigned to bring those skin-improving changes into the Beyonwiz firmware directly, but I think that PeterU's preference is to make sure the changes are adopted at the source first and them merge them down to Beyonwiz with all the other code when the opportunity arises. Doing it the other way around would be quite tricky.
(There is a lot of tricky history behind this that I am probably not getting 100% right, so please don't interpret this as me speaking on anyone's behalf. Just my outsider's observation)

[IanSav]

Hi Prl,

The thing that puzzles me is why it only seems to affect OverlayHD. An alternative explanation to anti-aliasing is that it is a text border (but I can't see any evidence in the code that one is used). I can't think why aliasing would generate a colour that contrasts so strongly with both the text and the background.

Is the issue specific to Beyonwiz models or firmware versions?

I have never explored using the Graphics mode of the EPG before. I will investigate this issue to see if I can explain and fix it. (I have a better understanding and better tools for managing graphical images these days.)

Regards,
Ian.

[prl]

Practically speaking I don't think any major upstream merges can happen in the 19.3 series since 19.3 was focused on making something work for the V2 that could be kept in sync with the T and U series firmware.

19.3 firmware is available on all models now (only as a public beta on models other than the V2).

I don't think that updating to the new versions of Directories.py, NumericalTextInput.py, VirtualKeyboard.py and MesageBox.py would be described as a "major merge", even though I believe some of the have been extensively re-written.

I'm also not sure which of them have made it into official releases of any of the enigma2 images that are (at the moment) incorporating them (OpenViX, OpenATV & Open PLi).

Every now and then IanSav prods me about merging them, but the Help merge into ViX is a fairly big job. Most of the coding is done, but I'm now working my way through making the necessary changes to the ViX skins.

[IanSav]

Hi Stevebow,

Would it be possible to put any updates up on your feed meanwhile? The 19.3 public release could be some way off yet.

All the OverlayHD skin updates are going into my feed. The feed is capable of supplying updates for Beyonwiz, OpenATV, OpenPLi and OpenViX images. OverlayHD is now a standard skin available for OE-Alliance images.

The problem here is that PeterU refuses to merge in my code updates from me or from the upstream images. OpenATV, OpenPLi and OpenViX are already running my new code and have been for quite some time. Some of these changes affect skins. OverlayHD and the Beyonwiz "skin_default" have already been updated to use the new code. I don't have the time, resources or interest to maintain a regression OverlayHD build.

I have been excluded from being a Beyonwiz developer so I have no influence to bring the Beyonwiz firmware up to date with the other images. I believe that Prl is interested in bringing my code to Beyonwiz but he already has a lot on his plate. Prl will be able to advice of his plans in this matter.

Regards,
Ian.

[IanSav]

Hi MrQuade,

It goes a bit deeper than that. IanSav's current skin version relies on new features that are available in the major overseas enigma2 distributions, and those features aren't available in any of the Beyonwiz firmware versions yet.

Practically speaking I don't think any major upstream merges can happen in the 19.3 series since 19.3 was focused on making something work for the V2 that could be kept in sync with the T and U series firmware.

While I was ejected from being a Beyonwiz developer I still made every effort to allow easy integration of my changes into Beyonwiz firmware. It has still mostly never happened. (The HELP button automation was recently accepted to complete one of Prl's changes.)

Perhaps the next major update will be a big merge update and we get to see a whole slew of new features like we did last time there was a big merge.

(it's a lot of effort for PeterU to consolidate all the custom Beyonwiz stuff with the work being done in the overseas markets since there are lots of features that Aussies want that noone in Europe would want or need, so the code is quite different in places, and it is time consuming and somewhat risky to patch it all together, so it does require a good deal of PVR-crashing beta testing too )

You may never know how close Australia came to using OpenViX as the default firmware, for *all* Enigma2 based models, with most of the Australian options directly integrated into the build.

Now that I am an active developer in multiple images I am working hard to bring those images closer and to make code, plugins and skins more portable across the images. Unfortunately Beyonwiz's new contributor policies are moving Beyonwiz further away from the other images.

IanSav has long campaigned to bring those skin-improving changes into the Beyonwiz firmware directly, but I think that PeterU's preference is to make sure the changes are adopted at the source first and them merge them down to Beyonwiz with all the other code when the opportunity arises. Doing it the other way around would be quite tricky.
(There is a lot of tricky history behind this that I am probably not getting 100% right, so please don't interpret this as me speaking on anyone's behalf. Just my outsider's observation)

It could have worked either way. Initially my efforts with the other images was to address PeterU's demands for upstream compatibility. Even though my changes were all accepted into multiple upstream images the code was never accepted into the Beyonwiz firmware. My efforts were so successful that I was invited to become a major contributor to OE-Alliance images and other derivative images.

The details of recent history are not for public reporting, however it is unlikely that I will be invited to return to Beyonwiz and probably less likely for me to want to return.

Regards,
Ian.

[peteru]

While I was ejected from being a Beyonwiz developer

I have no idea what you are referring to with this statement. Your changes continue to be merged into the Beyonwiz code base as long as they make sense and are of adequate quality. The most recent merge was 10 days ago. This was delayed for a long time because you flatly refused to co-operate on updating the standard skins to use the feature you added. prl was kind enough to do that work, but there was no one preventing you from doing that.

[IanSav]

Hi PeterU,

The test hardware I was given for development was withdrawn and my access to developer areas of the forum was removed. I consider this to my invitation to no longer be a Beyonwiz developer. That is not all that happened but it is all I will say at this time.

The pull request you mentioned was raised on 2-Dec-2018, it was merged on 2-Aug-2019 - Eight months later! Not particularly timely especially given the change was two very simple lines that were well documented in the pull request and the accompanying manual. As a comparison, my code submissions to the other images which is often significantly more complicated and is usually merged within minutes or at most a few days. It would appear that many others consider my code to make sense and be of more than adequate quality. The treatment of my Beyonwiz pull requests suffered inappropriate delays and generally received comments that indicated that the contributions were not welcomed.

This particular merged pull request was complete and self contained. There was no down side in including it when it was submitted. It required no other changes *including* not requiring any skin changes. At the time I pointed out that the change would enhance the user experience for all OverlayHD users. (Readers of the linked reference should note the timing of the various posts!) Recently Prl wanted the benefits of the change in the included skins so he modified those skins. Now the change is suddenly acceptable. Is this a bias against me and/or OverlayHD users?

You repeatedly indicated to me that if I could get my changes incorporated into OpenViX you would merge them into the Beyonwiz firmware. My changes, including the HELP button request referenced here, are going into OpenATV, OpenPLi, OpenViX and other images but as yet you still have not merged any of these changes for the benefit of Beyonwiz users and developers. This is particularly interesting as you have now included the latest OE-Alliance default skin into the Beyonwiz firmware. This skin has been modified to support my new VirtualKeyBoard code but that code and other related changes are yet to be merged into the Beyonwiz firmware.

New look and more featured VirtualKeyBoard.

VirtualKeyBoard.jpg (293.31 KiB) Viewed 3545 times

I consider this treatment to be a strong indications that my contributions are not welcomed for Beyonwiz firmware. I will leave other readers to make their own conclusions.

Regards,
Ian.

[stevebow]

FWIW, a +1 from me to include IanSav's contributions. They are very good IMHO. It's a shame it has descended to this.

[Paul_oz53]

FWIW, a +1 from me to include IanSav's contributions. They are very good IMHO. It's a shame it has descended to this.

+1

[stephenh]

FWIW, a +1 from me to include IanSav's contributions. They are very good IMHO. It's a shame it has descended to this.

Another +1

[MrQuade]

It basically boils down to being fairly technically complicated to maintain consistency between the upstream Enigma2 distributions and the Beyonwiz fork.

Things will eventually be merged, but it will just take time. The last time this happened with the 16.1 update quite a lot of breakage and testing was required to get everything working again.

My own take is that if we can get the Beyonwiz timeshifting and skipping updates along with the IceTV plugin working on the OpenATV distribution, we should switch all the Beyonwiz firmware to that instead. Open ATV has a lot of nice features. That would also require quite a lot of effort and coordination though.

[IanSav]

Hi MrQuade,

It basically boils down to being fairly technically complicated to maintain consistency between the upstream Enigma2 distributions and the Beyonwiz fork.

Things will eventually be merged, but it will just take time. The last time this happened with the 16.1 update quite a lot of breakage and testing was required to get everything working again.

My own take is that if we can get the Beyonwiz timeshifting and skipping updates along with the IceTV plugin working on the OpenATV distribution, we should switch all the Beyonwiz firmware to that instead. Open ATV has a lot of nice features. That would also require quite a lot of effort and coordination though.

Okay, here is another undocumented snippet. Jai sent me on a secret squirrel mission to work with OpenViX to integrate most of the important Beyonwiz features into OpenViX so that the new Beyonwiz firmware would be OpenViX. The Beyonwiz firmware was borne out of OpenViX which is itself a derivative of OpenPLi. I spent months on that project and engaged the support of OpenViX developers and administrators to make it happen. Our first effort was a hybrid of OpenATV drivers merged into OpenViX. (OpenATV is another derivative of OpenViX that began to diverge significantly from OpenViX about eight years ago.) That mostly worked but was unstable. After spending a few days, working 24 hours a day we had a full native OpenViX running correctly on the new Beyonwiz V2 hardware. Prl and I began porting Beyonwiz features over to OpenViX. Once we had a working OpenViX on V2 hardware Jai refused to accept or test our work and told us not bother as Beyonwiz was going to use OpenATV. I was then asked to do something, that was in my opinion, unethical which I refused to do. I detailed my objections and opinions which were taken in a bad way and was kicked off the Beyonwiz team.

I am now part of the OpenATV, OpenPLi and OpenViX teams. I am continuing to integrate Beyonwiz features into their code bases. Prl, when available, is also continuing to assist in migrating Beyonwiz features into OpenViX. I then attempt to replicate his changes into OpenPLi and OpenATV. For example, Prl has worked miracles on the Help code. It is significantly improved in the new OpenViX version. When finished Prl will back port the new code to Beyonwiz while I will try and duplicate it on OpenPLI and OpenATV. I am hoping that Prl will continue to help improve the other images with more projects in the future.

As for my new code not being integrated into Beyonwiz, as I mentioned before, all my changes were made with Beyonwiz in mind. The code is very easy to integrate into Beyonwiz firmware. I continue to test the changes on a Beyonwiz box! I strongly believe that my code is not merged for reasons other than image consistency and mergeablity.

Regards,
Ian.