Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[markf2748]

Download 64-bit build
https://files.jriver-cdn.com/mediacenter/channels/v33/latest/MediaCenter330060-x64.exe (works on 64 bit systems only)

33.0.57 (1/14/2025)

1. Changed: The rendering order of popup menus is revised slightly so transparency will no longer include stale submenus.

Thanks for fixing the dropdown transparency issue.  All dropdown menus and their submenus now display proper transparency for stationary backgrounds. 

FYI:  Inconsistent "painting order" between any dropdown and its submenus remains a visible issue for skin designs which have different colors in the first two pixels of the left and right vertical borders.  The attached images illustrate what happens:
1) For 1st submenu pick, the submenu appears on top of its source menu (preferred).
2) For 2nd and all subsequent submenu picks from a given source menu instance, the submenu appears below its source menu (undesirable).

I also attach the skin file menu_background.png which i used for testing with <MENU> Item code:

Code: [Select]

        <Entry Name="Back" Bitmap="Menu_Background.png" Scale="2" Margins="8,4,4,4" />
My preference is to always have a submenu appear on top of its respective source menu.  That provides maximum design flexibility and "newest on top" makes logical sense as well (to me at least).  The workaround is a mild constraint: first 2 pixel columns and last 2 pixel columns must be the same.  As mentioned previously, I have no issue with the 2-pixel overlap itself - in fact I prefer it.

[39505399]

The font foreground color is inconsistent. Please allow users to customize it.

[HPBEME]

Hey Matt, your recent fix to the menu transparency issue that markf2748 flagged has been great.

It has greatly improved the menu/submenu appearance for how I create menu backgrounds for my skin.  My approach is actually the opposite of your intent of having a slight overlap.  I instead create the images to force a visible gap/separation between the primary and submenus (see pics below). I considered asking you to address the stale/frozen image in the gap for some time now, but Mark has taken care of it.

That said, given that I have 10 different menu backgrounds that I like to rotate amongst for my skin (four of them shown below), I'm hoping that whatever fix you need to apply to address Mark's request above won't change how well they are now working. Thanks for your consideration in advance.

[Matt]

I think the fix is to simply get rid of the 2 pixel overlap. That causes menus to draw inconsistent based on the z-ordering of the windows. It might make your skins use an even slightly larger gap between menus, but no big deal. You could always trim if you wanted after the change.

[markf2748]

I think the fix is to simply get rid of the 2 pixel overlap. That causes menus to draw inconsistent based on the z-ordering of the windows. It might make your skins use an even slightly larger gap between menus, but no big deal. You could always trim if you wanted after the change.

If you must get rid of the 2 pixel overlap because of uncontrollable z-ordering, then please leave exactly 0 pixels between menu and submenu, i.e. they should be perfectly adjacent with no gap between them.  I too would expect that in this case anyone who prefers a small gap will still be able to get it by adjusting their skin Menu Background.  But if you build in a fixed gap >0 pixels, then AFAIK a designer who desires a continuous look can never fill the gap. 

The significant downside to removing the 2 pixel overlap, instead of controlling z-ordering: For skins with a symmetric Menu outline W pixels wide, this border becomes 2W wide where the menu and submenu are adjacent (assuming no gap), and then suddenly drops to W pixels wide where the menu and submenu are no longer adjacent. This will change the appearance of some existing skins.  I would find it especially disturbing for a dropdown which stretches vertically beyond the border of its source menu. On the contrary, for a 2 pixel overlap, the respective widths are 2W-2 and W.  When W=2 there is no change in width between overlapping and non-overlapping borders.

HPBEME's built-in Dream in Blue is a good example of a skin with 2 pixel uniform borders all around which will surely be impacted by removing the 2 pixel overlap.

Side Note:  I imagine some readers are astonished that we care about 1 or 2 pixel gaps, as I once was!  But in practice, a 1 or 2 pixel gap/feature can be very noticeable when contrasting colors are involved.   It is a testament to the quality of MC's software that it offers such tight display control at the pixel level.  Upon close observation, I find the same edge behavior on two old 1920x1080 monitors with different aspect ratios and a new 4K 3840x2160 desktop monitor, over a wide range of Windows Display Resolution settings and MC Size settings.  For example, a controlled 2 pixel wide line is always rendered two pixels wide (only the apparent size of a "pixel" changes). Worst case variation I have seen is an additional 1 pixel of color aliasing.

1/23/2025 - Some updates for clarity.
2/1/2025 - JRiver removed the 2 pixel overlap in Version 33.0.61, included in Public Release 33.0.63 (1/30/2025).  The first column of a submenu dropdown now appears fixed in the first column to the right of the source's last column, i.e. the menus are adjacent with zero gap instead of overlapped.  Confirmed.

[zeltak]

Thanks for fixing the dropdown transparency issue.  All dropdown menus and their submenus now display proper transparency for stationary backgrounds. 

@markf2748 and all

how do you get the cool horizontal menu (see attachment)?

thx so much

Z

[markf2748]

@markf2748 and all

how do you get the cool horizontal menu (see attachment)?

Thanks.  It's a long custom skinning story (unreleased minimalist journey) which should be opened in a different thread.  But FYI, attachment shows another feature: mouseover on a View Tab does not change its text or color.  Instead it just adds a small highlight to the tab's upper left corner, above the lock symbol! 

[HPBEME]

how do you get the cool horizontal menu (see attachment)?

What you highlighted in your screenshot is not a "horizontal menu" - those are "view tabs".

You can easily add these tabs yourself by middle-clicking any item listed in the tree at the left.  Middle clicking various tree items will keep adding them (horizontally) as a new tabs.  If you left-click instead of middle click, MC will replace what is shown in the active tab (unless the tab is locked, which also results in a new tab so the locked tab does not get overwritten).

I just wanted to clarify MC allows users to easily show many tabs (horizontally) across the top of the main content area and is not an advanced setting, in the event that was not understood.

[HPBEME]

HPBEME's built-in Dream in Blue is a good example of a skin with 2 pixel uniform borders all around which will surely be impacted by removing the 2 pixel overlap.

I have no objections to whether the two pixel overlap is kept or not. I can adjust the width of my menus transparent margins and the image control parameters in the XML as needed, so I don't anticipate this will be an issue for me. I already do some very funky things with my skin's images to achieve the look I am after. 

My previous post was me just wanting to make sure that the recent transparency fix was not further adjusted in a way that undid it.  It does not sound like that will be the case.

I imagine some readers are astonished that we care about 1 or 2 pixel gaps, as I once was!  But in practice, a 1 or 2 pixel gap/feature can be very noticeable when contrasting colors are involved. 

This is true.  When I work on my skins, I am always amazed how big a visual impact adjusting a particular element within a sub-image by only 1 or 2 pixels can have.

[zeltak]

I just wanted to clarify MC allows users to easily show many tabs (horizontally) across the top of the main content area and is not an advanced setting, in the event that was not understood.

thx for the clarification!!

Z

[markf2748]

Re borders:

1) Add a new Skin Attribute:  <MENU>  <Colors ... SubmenuOffset="xx" ... />  </MENU>
2) Range: -6 <= xx <= 20.  Negative values produce overlap, positive values space the submenu to the right of its source menu.  Lower limit suggested to avoid interference with source menu's right arrow.  Upper limit is arbitrary.
3) Omission/Default = -2 reproduces current behavior without affecting legacy skins.
4) Control z-ordering so submenu dropdown is always above its source menu, which is important for xx<0.

Advantages:
1) Simple skin setting covers all the bases.
2) No need for transparent left border columns to simulate spacing.  For xx>0, the transparency never encroaches on the submenu checkmark, even for large spacing.
3) For xx<0, symmetric left and right borders of width = |xx| produce uninterrupted vertical borders having possible widths 1-6 pixels.
4) By including in the <Colors ... /> entry, it can be applied even without specifying Bitmap images. (?)

No idea how hard this would be to implement, but it adds considerable flexibility for the skin designer.

2/1/2025 - JRiver removed the 2 pixel overlap in Version 33.0.61, included in Public Release 33.0.63 (1/30/2025).  The first column of a submenu dropdown now appears fixed in the first column to the right of the source's last column, i.e. the source menu and dropdown submenu are adjacent with zero gap instead of overlapped. Confirmed.