Please guys, reread my posts carefully (I know, they tend to be verbose...). I raised two different issues:
I was testing the the Green Eyes skin. There's a couple pixel overlap, but that seems fine to me.
Are you just requesting the popup be made a little farther to the right so there's no overlap? Thanks.
(1) No. My third party post (which I prefer to see restored
since it clearly illustrates the issue), only discusses the 2-pixel border overlap. I have no issue with it per se, in fact I prefer the overlap for reasons stated there (no leakage of underlying window through a possible border gap). I also prefer the look, it is more "connected", and allows for designing continuous outlines between menus. The only request is maintaining a consistent drawing order in the endpoint image which the viewer sees.
Ideally, in every step the most recently opened submenu should be drawn on top of its predecessor (i.e. source) menu, which does not happen now. However this only turns into a real visible problem when the outermost 2 pixels of the left and right dropdown borders are different. While current behavior results in this design constraint, it is not an issue for most skins. For example, the problem appears for skin
Black and Blue, but not for
Black and Blue Too.
(2) In current thread, I raise the issue of errors in drawing transparent multilevel dropdown menus. That is totally different and more serious since I do not have even a partial workaround and I find it quite apparent in skins with transparent dropdowns.
The root cause in both issues has something to do with redrawing, but the fundamentals may be very different. Thanks.
The series of images from Mark show that each submenu is rendered on top of the previous submenu, which is then partially visible through the transparency effect. The previous submenu is blurred out, but if you look carefully you can see that the text and arrows of the previous menu is still there instead of the underlying poster.
It's not so visible on some skins, but it's reproducible. Just hover a bit over each submenu item to open them in succession. Looks like the existing menu rectangle is resized and reused, but not cleared.
Yes. I noticed this, and agree it is 100% reproducible, but could not quite pin down what those undesired images are for certain.
When it goes to render transparency it grabs what was on the screen for the transparent section. So if the menu was there, it's going to use that. I'm wondering if we destroy the old menu before showing the new one if that might work?
Likely the cause. As long as you retain clean transparent snapshots of the whole dropdown chain in the final image, and if you also implement a consistent drawing order as described, then both issues should be fixed.
Comment re Green Eyes skin (Matt's Reply #1): The dropdown menus in this light skin have a one pixel wide dark border symmetric all around, plus asymmetric internal artwork, governed by this line in its main.xml file:<MENU> ... <Entry Name="Back" Bitmap="Menu_back.png" Margins="7,2,2,2" DrawMode="REGION_E_HSTRETCH,REGION_E_VTILE" /> </MENU>The border artwork of Menu_back.png is stabilized with the Margins parameter. There is only a small 2-pixel overlap display issue - most dark vertical border lines are offset by one pixel between the menu and its submenu, but this is only apparent on very close examination. I believe this would be corrected by having identical 2-pixel left and right borders. Of course Green Eyes transparent drop down menus exhibit the transparency issue described in this thread. Thanks for bringing Green Eyes to my attention - its Menu_back.png file is very interesting.1/9/2025 Multiple edits for clarification.
Author
Topic: Bug: Transparency errors in dropdown menus (Read 391 times)