Explorer glass border glitch

There is no need to have transparency on the border itself, insert it into the shadow images to achieve the effect you wish. 

If you're still having issues, send it via PM and I'll take a look to see what the problem is.

"Put detail into what people look at, don´t spend hours on what they don´t"

-Boris Vallejo

@roflmfaoo: Actually... there is The original OS X border frames are 1px large and have such dark semi-transparent border. I want to make my skin exactly the same. Also, if I don't set any borders and use shadows only, I will be unable to resize the window horizontally by dragging the left and right borders. Even like this I'm still having issue since windows considers a semi-transparent border like a non-existing border... the Echo skin was the only one able to face this issue.

@neone6: ahahah... yeah... but that's a pretty noticeable glitch mate, I can't just pass over it

Anyway, here's the skin .wba package. Have a look at it:

https://drive.google.com/file/d/0B9uTCyb7q8yXWkM4aFRhOW5mLTA/edit?usp=sharing

(please don't use it to make derived works... I wasn't even planning on releasing it)

I see an issue with your blind, you have included shadow to the border images as well as including shadow images under the shadow section. I tested my theory and created a set of new borders (on a new blind) with the 1px semi-transparent border, the result was no blurring when overlaying a variety of colours. On your per pixel frames, remove the shadow but leave the 1px semi-transparent border then create your shadows using this method (courtesy of DanilloOc)

 

From here you will find that this should rectify your issue. Also to note, it's far easier now to save as *.PNG format, since you don't have to deal with the alpha channel directly as you do with *.TGA.

@neone6: guy

@roflmfaoo: I built the border images with 1px actual border and 2px shadow on the left and right borders because if I didn't do so Windows would not let windows resize horizontally anymore (the border wouldn't be recognized as such with the 1px border only, so Windows would never show the resize arrows). But the shadows are calculated to work fine:

As you can see in the image above, on the left there is the composed window when all parts are put together, in the center there is the parts mask (darker for borders, lighter for shadows), and on the right a semi-transparent parts mask over the composed window which clearly shows each part's boundaries. But you can clearly see the issue in my skin is not related to my sources at all. In fact, any window that doesn't use an extended glass border will use the correct border color. Only windows that extend the glass area will create this glitch, and the glitch is created just near the extended glass border. If my sources were using a wrong border color you would notice it in the image above. If I was using any wrong painting margins the borders would result in a much stretched and pixelated image but never in a more transparent border. In the window previews in SkinStudio and WindowBlinds you can clearly see the borders are painted correctly.

The point though is not whether this is a bug/glitch in WindowBlinds or SkinStudio, it's about how may I fix this? If you manage to fix it for me let me know,but I am trying since a few days now to rework all the sources in many ways with always the same result...

BTW, I am already using PNG 32-bit files in my sources, but SkinStudio converts them to TGA and I can do nothing about this.

Sorry for the late reply, upon testing I found that the only area to be affected was the "upper glass area" what happens is the transparency is blurred like the aero blur rather than using semi-transparency. My point with the *.PNG format was that ticking pre-multiplied alpha isn't necessary when using this format. Even though SKS converts *.PNG to *.TGA. I'll continue to look at this and hopefully we can find out a fix for this issue. 

Oh OK. If you ever find out some pre-multiplied alpha ticks in the skins that's either because it was already like that in the Echo skin, or because of my different tests of settings around the skin when I got this issue.
BTW, I already tried adding BackgroundEffect=0 to the top glass area part but it doesn't change anything. I suppose it might be a WindowBlinds bug after all... so I'll be waiting for your advice, let me know if there's anything I can do to help you with this issue.

I have some good news for you T3STY. The issue is resolved by editing the code under the section Window Frames > Per Pixel > Borders (select this) > On the code editor tab, change "BackgroundEffect=0" to "BackgroundEffect=1". Save & apply. 

Sorry for my late reply too!

Thank you very very much! That's just an absurd tweak since this code should enable the blur behind windows - which is what don't want - but still enabling it would not blur the background and would fix the issue.

Thank you again for your help!

its not a tweak really, if one section of the borders has a different setting than another then it throws things off. So setting the backgroundeffect on the code editor tab for all the borders rectifies this issue. It's something people don't quite realise, that skins are compiled using code and SKS removes the need for the user to learn it by allowing the skinner to import each image and set the margins then SKS does the rest.

Ive notices similarities but in an internal pixel inside de border of chrome and firefox.